[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fiYBlmJXeLtn53YuwwDpnNZAyEsqpPYdPmF7wkuI4k6E":3},{"slug":4,"title":5,"published":6,"publishedAt":7,"createdAt":8,"section":9,"preview":10,"heroImage":9,"previewImage":11,"headMarkup":12,"bodyMd":13,"bodyHtml":14},"migratsiya-s-megaplana-na-bitrix24-opyt-fabrikant","Миграция с Мегаплана на Битрикс24: опыт переноса сделок оконной компании",true,"01.09.2025 00:00:00","2026-07-17T20:43:13.476Z",null,"В сентябре 2025 года к нам перешёл проект «ФабрикантЪ» — астраханский производитель окон и дверей. Предыдущая компания-интегратор настроила Битрикс24, но не...","\u002Fcontent-media\u002Farticles\u002Fmigratsiya-s-megaplana-na-bitrix24-opyt-fabrikant\u002Fassets\u002Fpreview.svg",[],"## Как проект оказался у нас\n\nВ сентябре 2025 года к нам обратилась компания астраханский производитель окон, дверей и светопрозрачных конструкций. Почти тридцать лет на рынке, два выставочных зала, собственное производство и больше тысячи установленных изделий в год.\n\nДо этого с компанией уже работал другой интегратор Битрикс24. Он настроил CRM: создал смарт-процесс для замеров, наладил воронки, прописал роботов. Но когда дошло до главного — переноса исторических данных из Мегаплана, где компания работала много лет — случилась пробуксовка. Интегратор не смог решить эту задачу. Проект застопорился.\n\nКлиент передал проект с конкретным запросом: «В Битрикс24 уже всё настроено, но сделок там нет. Перенесите данные из Мегаплана, и чтобы всё работало».\n\n## Что было в Мегаплане\n\nМегаплан — российская CRM, которую компания использовала для управления замерами. Внутри была схема сделок с программой №13, и в ней накопились сотни записей: выезды замерщиков, коммерческие предложения, договоры. Каждая сделка содержала:\n\n- Данные клиента: контактное лицо или компания, телефон, email\n- Параметры замера: адрес, дата и время, корпоративный или частный\n- Назначенного замерщика — конкретного сотрудника из бригады\n- Файлы замера: чертежи, схемы, фотографии объектов\n- Комментарий к замеру и сумму договора\n- Премию замерщику и зону доставки\n- Связанные сделки (в Битрикс24 уже были созданы параллельные сделки, которые надо было слинковать)\n\nМегаплан отдаёт данные через REST API v3. Документация есть, но не сахар: пагинация курсорная, состав полей зависит от конкретной схемы сделок, файлы нужно вытягивать отдельным запросом и прокидывать через base64.\n\nПредыдущий интегратор попытался решить задачу и не довёл до конца. Работа началась с изучения того, что уже было сделано на стороне Битрикс24, и затем — с погружения в API Мегаплана.\n\n## Что было сделано\n\n### Изучение API Мегаплана и разработка приложения\n\nПервым делом была поднята документация Мегаплана по API v3 и проверены все конечные точки, которые потребуются:\n\n- `\u002Fapi\u002Fv3\u002Fdeal` — список сделок с фильтрацией по программе и пагинацией по 100 записей\n- `\u002Fapi\u002Fv3\u002Fdeal\u002F{id}` — полная карточка сделки со всеми кастомными полями\n- `\u002Fapi\u002Fv3\u002Fdeal\u002F{id}\u002FlinkedDeals` — связанные сделки\n- `\u002Fapi\u002Fv3\u002Fdeal\u002F{id}\u002FallFiles` — файлы, прикреплённые к сделке\n- Скачивание файлов по внутренним путям Мегаплана с Bearer-аутентификацией\n\nЗатем было написано приложение для Битрикс24 — компонент `fabricant_v1`, работающий внутри фреймворка Битрикс24 и использующий REST-клиент для общения с обоими API.\n\n### Пайплайн миграции\n\nЛогика переноса состоит из трёх этапов:\n\n**Этап 1. Сбор данных из Мегаплана.** Приложение последовательно запрашивает все сделки из программы №13 через курсорную пагинацию. Для каждой сделки, у которой статус «выполнена» или «отменена» (id 99, 100, 101) и дата изменения раньше контрольной точки, запрашивается полная карточка с двадцатью кастомными полями: замерщик, адрес, дата замера, корпоративный замер, файлы, премия, сумма договора и другие.\n\n**Этап 2. Трансформация данных.** Каждое поле Мегаплана мапится в соответствующее пользовательское поле смарт-процесса Битрикс24:\n\n- Название сделки → заголовок элемента\n- Адрес замера → UF-поле адреса\n- Дата замера → UF-поле даты\n- Файлы замера → скачиваются из Мегаплана, кодируются в base64 и прикрепляются к элементу смарт-процесса\n- Замерщик → сопоставляется по справочнику из 14 фамилий с ID пользователей Битрикс24\n- Тип клиента (компания или контакт) → поиск существующего контакта или компании в Битрикс24 по телефону и email\n- Статус сделки (99\u002F100 = успешно, 101 = провал) → стадия смарт-процесса SUCCESS или FAIL\n- Наблюдатели и ответственные → поиск по имени и фамилии среди пользователей портала\n\n**Этап 3. Загрузка в Битрикс24 с дедупликацией.** Перед созданием каждого элемента приложение проверяет: нет ли уже записи с такой же ссылкой на сделку Мегаплана. Если есть — пропускает. Если нет — создаёт новый элемент смарт-процесса 1040 с заполненными UF-полями, файлами и привязкой к сделке Битрикс24.\n\n### Связанные сделки\n\nОдна из нетривиальных частей — привязка элементов смарт-процесса к уже существующим сделкам Битрикс24. Мегаплан хранит связи между сделками, и часть из них ссылается на сделки, которые уже были созданы в Битрикс24 предыдущим интегратором.\n\nПриложение запрашивает связанные сделки через `\u002Fapi\u002Fv3\u002Fdeal\u002F{id}\u002FlinkedDeals`, ищет соответствующие сделки в Битрикс24 по пользовательскому полю с URL Мегаплана, и при нахождении единственного совпадения привязывает элемент смарт-процесса к найденной сделке.\n\n### Обработка файлов\n\nФайлы в Мегаплане хранятся на внутреннем файловом сервере. Приложение скачивает каждый файл через HTTP-клиент Битрикс24 с Bearer-авторизацией, определяет MIME-тип, кодирует в base64 и прикрепляет к элементу смарт-процесса через множественное UF-поле. Имена файлов сохраняются оригинальные.\n\n## Какие данные были перенесены\n\nВ результате миграции в Битрикс24 попали:\n\n- Сделки из программы замеров Мегаплана (схема №13, статусы 99\u002F100\u002F101) — в смарт-процесс 1040\n- 20+ пользовательских полей: адрес замера, дата, замерщик, сумма договора, премия, зона доставки, форма оплаты\n- Файлы замера (чертежи, схемы, фотографии)\n- Клиенты: контакты и компании с телефонами и email\n- Связи: найденные сделки Битрикс24 прилинкованы к элементам смарт-процесса\n- Наблюдатели и ответственные из числа сотрудников портала\n\n## Что пошло не так у предыдущего интегратора\n\nНесколько вероятных причин, почему предыдущая попытка миграции не увенчалась успехом:\n\n**Курсорная пагинация.** Мегаплан v3 использует курсорную пагинацию через `pageAfter` с указанием ID последней записи и её contentType. Это не тривиальный offset\u002Flimit — нужно аккуратно обрабатывать рекурсивные запросы, проверять флаг `hasMoreNext` и не терять данные на стыках страниц.\n\n**Кастомные поля с префиксами схем.** Поля в API Мегаплана возвращаются с префиксом конкретной схемы: `Category1000060CustomFieldAdresZamera`, а не просто `AdresZamera`. Без знания ID схемы найти нужные поля невозможно — их надо вычислять.\n\n**Связь сделок через linkedDeals.** Связанные сделки в Мегаплане — это отдельный endpoint. Предыдущий интегратор мог не учесть, что часть сделок уже создана в Битрикс24 и их нужно искать по кастомному полю с URL Мегаплана, а не создавать заново.\n\n**Справочник замерщиков.** 14 фамилий замерщиков из Мегаплана нужно было сопоставить с ID пользователей Битрикс24. Часть из них не имела прямого соответствия — пришлось использовать текстовые комментарии вместо числовых привязок.\n\n**Файлы.** Скачивание файлов из Мегаплана требует отдельной обработки: авторизация Bearer, определение MIME-типа, base64-кодирование, загрузка в множественное UF-поле Битрикс24. Это не копирование ссылок, а полноценный перенос бинарных данных.\n\n## Технический стек\n\n- **Мегаплан API v3** — REST, Bearer-аутентификация, курсорная пагинация\n- **Битрикс24 REST API** — через модуль `swebs.rest2` (обёртка над стандартным API)\n- **Приложение** — PHP-компонент для Битрикс24 Marketplace\n- **Смарт-процесс 1040** — целевая сущность для замеров в Битрикс24\n- **Дедупликация** — через UF-поле с URL сделки Мегаплана\n\n## Итог\n\nПроект, который застопорился у предыдущего интегратора, был завершён. компания получила работающую CRM с полным набором исторических данных: сотни замеров, клиентская база, файлы, ответственные и связи между сущностями — всё, что накопилось за годы работы в Мегаплане.\n\nПеренос занял один проход. Ни одной потерянной записи. Ни одного дубликата.","\u003Ch2>Как проект оказался у нас\u003C\u002Fh2>\n\u003Cp>В сентябре 2025 года к нам обратилась компания астраханский производитель окон, дверей и светопрозрачных конструкций. Почти тридцать лет на рынке, два выставочных зала, собственное производство и больше тысячи установленных изделий в год.\u003C\u002Fp>\n\u003Cp>До этого с компанией уже работал другой интегратор Битрикс24. Он настроил CRM: создал смарт-процесс для замеров, наладил воронки, прописал роботов. Но когда дошло до главного — переноса исторических данных из Мегаплана, где компания работала много лет — случилась пробуксовка. Интегратор не смог решить эту задачу. Проект застопорился.\u003C\u002Fp>\n\u003Cp>Клиент передал проект с конкретным запросом: «В Битрикс24 уже всё настроено, но сделок там нет. Перенесите данные из Мегаплана, и чтобы всё работало».\u003C\u002Fp>\n\u003Ch2>Что было в Мегаплане\u003C\u002Fh2>\n\u003Cp>Мегаплан — российская CRM, которую компания использовала для управления замерами. Внутри была схема сделок с программой №13, и в ней накопились сотни записей: выезды замерщиков, коммерческие предложения, договоры. Каждая сделка содержала:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Данные клиента: контактное лицо или компания, телефон, email\u003C\u002Fli>\n\u003Cli>Параметры замера: адрес, дата и время, корпоративный или частный\u003C\u002Fli>\n\u003Cli>Назначенного замерщика — конкретного сотрудника из бригады\u003C\u002Fli>\n\u003Cli>Файлы замера: чертежи, схемы, фотографии объектов\u003C\u002Fli>\n\u003Cli>Комментарий к замеру и сумму договора\u003C\u002Fli>\n\u003Cli>Премию замерщику и зону доставки\u003C\u002Fli>\n\u003Cli>Связанные сделки (в Битрикс24 уже были созданы параллельные сделки, которые надо было слинковать)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Мегаплан отдаёт данные через REST API v3. Документация есть, но не сахар: пагинация курсорная, состав полей зависит от конкретной схемы сделок, файлы нужно вытягивать отдельным запросом и прокидывать через base64.\u003C\u002Fp>\n\u003Cp>Предыдущий интегратор попытался решить задачу и не довёл до конца. Работа началась с изучения того, что уже было сделано на стороне Битрикс24, и затем — с погружения в API Мегаплана.\u003C\u002Fp>\n\u003Ch2>Что было сделано\u003C\u002Fh2>\n\u003Ch3>Изучение API Мегаплана и разработка приложения\u003C\u002Fh3>\n\u003Cp>Первым делом была поднята документация Мегаплана по API v3 и проверены все конечные точки, которые потребуются:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Ccode>\u002Fapi\u002Fv3\u002Fdeal\u003C\u002Fcode> — список сделок с фильтрацией по программе и пагинацией по 100 записей\u003C\u002Fli>\n\u003Cli>\u003Ccode>\u002Fapi\u002Fv3\u002Fdeal\u002F{id}\u003C\u002Fcode> — полная карточка сделки со всеми кастомными полями\u003C\u002Fli>\n\u003Cli>\u003Ccode>\u002Fapi\u002Fv3\u002Fdeal\u002F{id}\u002FlinkedDeals\u003C\u002Fcode> — связанные сделки\u003C\u002Fli>\n\u003Cli>\u003Ccode>\u002Fapi\u002Fv3\u002Fdeal\u002F{id}\u002FallFiles\u003C\u002Fcode> — файлы, прикреплённые к сделке\u003C\u002Fli>\n\u003Cli>Скачивание файлов по внутренним путям Мегаплана с Bearer-аутентификацией\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Затем было написано приложение для Битрикс24 — компонент \u003Ccode>fabricant_v1\u003C\u002Fcode>, работающий внутри фреймворка Битрикс24 и использующий REST-клиент для общения с обоими API.\u003C\u002Fp>\n\u003Ch3>Пайплайн миграции\u003C\u002Fh3>\n\u003Cp>Логика переноса состоит из трёх этапов:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Этап 1. Сбор данных из Мегаплана.\u003C\u002Fstrong> Приложение последовательно запрашивает все сделки из программы №13 через курсорную пагинацию. Для каждой сделки, у которой статус «выполнена» или «отменена» (id 99, 100, 101) и дата изменения раньше контрольной точки, запрашивается полная карточка с двадцатью кастомными полями: замерщик, адрес, дата замера, корпоративный замер, файлы, премия, сумма договора и другие.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Этап 2. Трансформация данных.\u003C\u002Fstrong> Каждое поле Мегаплана мапится в соответствующее пользовательское поле смарт-процесса Битрикс24:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Название сделки → заголовок элемента\u003C\u002Fli>\n\u003Cli>Адрес замера → UF-поле адреса\u003C\u002Fli>\n\u003Cli>Дата замера → UF-поле даты\u003C\u002Fli>\n\u003Cli>Файлы замера → скачиваются из Мегаплана, кодируются в base64 и прикрепляются к элементу смарт-процесса\u003C\u002Fli>\n\u003Cli>Замерщик → сопоставляется по справочнику из 14 фамилий с ID пользователей Битрикс24\u003C\u002Fli>\n\u003Cli>Тип клиента (компания или контакт) → поиск существующего контакта или компании в Битрикс24 по телефону и email\u003C\u002Fli>\n\u003Cli>Статус сделки (99\u002F100 = успешно, 101 = провал) → стадия смарт-процесса SUCCESS или FAIL\u003C\u002Fli>\n\u003Cli>Наблюдатели и ответственные → поиск по имени и фамилии среди пользователей портала\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Этап 3. Загрузка в Битрикс24 с дедупликацией.\u003C\u002Fstrong> Перед созданием каждого элемента приложение проверяет: нет ли уже записи с такой же ссылкой на сделку Мегаплана. Если есть — пропускает. Если нет — создаёт новый элемент смарт-процесса 1040 с заполненными UF-полями, файлами и привязкой к сделке Битрикс24.\u003C\u002Fp>\n\u003Ch3>Связанные сделки\u003C\u002Fh3>\n\u003Cp>Одна из нетривиальных частей — привязка элементов смарт-процесса к уже существующим сделкам Битрикс24. Мегаплан хранит связи между сделками, и часть из них ссылается на сделки, которые уже были созданы в Битрикс24 предыдущим интегратором.\u003C\u002Fp>\n\u003Cp>Приложение запрашивает связанные сделки через \u003Ccode>\u002Fapi\u002Fv3\u002Fdeal\u002F{id}\u002FlinkedDeals\u003C\u002Fcode>, ищет соответствующие сделки в Битрикс24 по пользовательскому полю с URL Мегаплана, и при нахождении единственного совпадения привязывает элемент смарт-процесса к найденной сделке.\u003C\u002Fp>\n\u003Ch3>Обработка файлов\u003C\u002Fh3>\n\u003Cp>Файлы в Мегаплане хранятся на внутреннем файловом сервере. Приложение скачивает каждый файл через HTTP-клиент Битрикс24 с Bearer-авторизацией, определяет MIME-тип, кодирует в base64 и прикрепляет к элементу смарт-процесса через множественное UF-поле. Имена файлов сохраняются оригинальные.\u003C\u002Fp>\n\u003Ch2>Какие данные были перенесены\u003C\u002Fh2>\n\u003Cp>В результате миграции в Битрикс24 попали:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Сделки из программы замеров Мегаплана (схема №13, статусы 99\u002F100\u002F101) — в смарт-процесс 1040\u003C\u002Fli>\n\u003Cli>20+ пользовательских полей: адрес замера, дата, замерщик, сумма договора, премия, зона доставки, форма оплаты\u003C\u002Fli>\n\u003Cli>Файлы замера (чертежи, схемы, фотографии)\u003C\u002Fli>\n\u003Cli>Клиенты: контакты и компании с телефонами и email\u003C\u002Fli>\n\u003Cli>Связи: найденные сделки Битрикс24 прилинкованы к элементам смарт-процесса\u003C\u002Fli>\n\u003Cli>Наблюдатели и ответственные из числа сотрудников портала\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Что пошло не так у предыдущего интегратора\u003C\u002Fh2>\n\u003Cp>Несколько вероятных причин, почему предыдущая попытка миграции не увенчалась успехом:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Курсорная пагинация.\u003C\u002Fstrong> Мегаплан v3 использует курсорную пагинацию через \u003Ccode>pageAfter\u003C\u002Fcode> с указанием ID последней записи и её contentType. Это не тривиальный offset\u002Flimit — нужно аккуратно обрабатывать рекурсивные запросы, проверять флаг \u003Ccode>hasMoreNext\u003C\u002Fcode> и не терять данные на стыках страниц.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Кастомные поля с префиксами схем.\u003C\u002Fstrong> Поля в API Мегаплана возвращаются с префиксом конкретной схемы: \u003Ccode>Category1000060CustomFieldAdresZamera\u003C\u002Fcode>, а не просто \u003Ccode>AdresZamera\u003C\u002Fcode>. Без знания ID схемы найти нужные поля невозможно — их надо вычислять.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Связь сделок через linkedDeals.\u003C\u002Fstrong> Связанные сделки в Мегаплане — это отдельный endpoint. Предыдущий интегратор мог не учесть, что часть сделок уже создана в Битрикс24 и их нужно искать по кастомному полю с URL Мегаплана, а не создавать заново.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Справочник замерщиков.\u003C\u002Fstrong> 14 фамилий замерщиков из Мегаплана нужно было сопоставить с ID пользователей Битрикс24. Часть из них не имела прямого соответствия — пришлось использовать текстовые комментарии вместо числовых привязок.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Файлы.\u003C\u002Fstrong> Скачивание файлов из Мегаплана требует отдельной обработки: авторизация Bearer, определение MIME-типа, base64-кодирование, загрузка в множественное UF-поле Битрикс24. Это не копирование ссылок, а полноценный перенос бинарных данных.\u003C\u002Fp>\n\u003Ch2>Технический стек\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Мегаплан API v3\u003C\u002Fstrong> — REST, Bearer-аутентификация, курсорная пагинация\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Битрикс24 REST API\u003C\u002Fstrong> — через модуль \u003Ccode>swebs.rest2\u003C\u002Fcode> (обёртка над стандартным API)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Приложение\u003C\u002Fstrong> — PHP-компонент для Битрикс24 Marketplace\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Смарт-процесс 1040\u003C\u002Fstrong> — целевая сущность для замеров в Битрикс24\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Дедупликация\u003C\u002Fstrong> — через UF-поле с URL сделки Мегаплана\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>Итог\u003C\u002Fh2>\n\u003Cp>Проект, который застопорился у предыдущего интегратора, был завершён. компания получила работающую CRM с полным набором исторических данных: сотни замеров, клиентская база, файлы, ответственные и связи между сущностями — всё, что накопилось за годы работы в Мегаплане.\u003C\u002Fp>\n\u003Cp>Перенос занял один проход. Ни одной потерянной записи. Ни одного дубликата.\u003C\u002Fp>\n"]