Блокбастер «Операция «Интеграция». Вечная битва запросов amoCRM vs ERP РосБизнесСофт

Альфа Кейс — российский производитель защитных решений для хранения и транспортировки оборудования. С 2017 года компания выпускает более 120 моделей кейсов и контейнеров и создаёт индивидуальные решения. Надёжный поставщик для корпоративного и государственного сектора: в 2024 году выполнено свыше 50 контрактов по 44, 223 и 275-ФЗ с показателем своевременной поставки 99,8% из 4166 заказов.

Требуется создать интеграцию между AmoCRM и ERP системой РосБизнесСофт (РБС), чтобы сделки и связанные с ними данные автоматически передавались в ERP РБС

Мы — IT TIME NOW интегратор и уже более 5 лет работаем с CRM|ERP РосБизнесСофт и первым делом спросили, а зачем вам amoCRM? Ведь функционал CRM|ERP РосБизнесСофт закрывает полностью бизнес-процессы клиента.

По нашему мнению АльфаКейс стали заложниками ограниченности функционала amoCRM из-за чего пришлось набрасывать всё больше и больше функционала на вентилятор 😉 В IT TIME NOW мы всегда начинаем с аудита бизнес-процессов, чтобы точно подобрать систему под задачи клиента, а не подгонять бизнес под возможности продукта. К сожалению, на рынке нередко встречаются ситуации, когда решение выбирают без учёта будущего роста и требований компании.

Бизнес процесс Сделки проходит следующим образом Менеджер создает сделку в amoCRM → В специально разработанный калькуляторе в гуглдокс, делает расчет стоимости → нажимает кнопку передать данные в amoCRM → Заключение договора → передача в производство или на склад → доставка → Успех. Это если кратко, а так воронка Первичная продажа состоит из 15 этапов. Как результат сложный процесс обработки заявки, без возможности учета производственных и складских процессов.

Владельцем было принято решение перенести бизнес-процессы производства в CRM|ERP РосБизнесСофт, а так как слишком много было сделано в amoCRM, решили сначала перенести только производственную часть.

И тут вступаем в игру мы! Всё начиналось хорошо 😉 Задача понятная и простая, +- мы такое делали. Оценили → согласовали → подписались → и в бой!

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

В амо нет каких-то универсальных полей данных. Если создать какое-то поле, ему присваивается определенный уникальный идентификатор в системе. Упаковка, Сборка и т.п. — у каждого есть не просто уникальный идентификатор, а еще и опция. Все это было принято во внимание и реализовано.

Но позже выяснилось, что через некоторый период поля перестают обрабатываться в РБС. Мы долго ломали голову, что за напасть такая. И при детальном разборе обнаружилось, что наша команда работала параллельно с другим разработчиком в amoCRM, который пересоздавал поля, меняя идентификаторы, в результате чего наш функционал ломался.

Когда мы работаем в РБС, то обычно мы контролируем, кто в системе может работать. Мы контролируем какие аккаунты имеют доступ к Конфигуратору. Что, за Конфигуратор? И еще момент, в одном аккаунте в РБС не может находится два пользовался с разных компьютеров. Одного из них выкинет. В данном проекте мы не контролировали доступы к АМО по этому вышел казус со сторонним разработчиком. Теперь перед началом работ мы уточняем у клиента, кто может ещё работать по проекту.

Конфигуратор — это специальный инструмент для настройки и доработки системы под нужды компании, без необходимости глубокой программной разработки в CRM|ERP РосБизнесСофт

По заданию требовалось брать сделки в РБС при смене статуса в amoCRM. Алгоритм следующий: сделка отправляется в РБС, смотрим в базе id сделки в amoCRM, если такой сделки нет — создаем, если есть — ответ игнорируем.

Но как оказалось, amoCRM может отправить не один запрос при изменении статуса Сделки, а сразу хоть 3, хоть 10 одновременно за 1-3 секунды. РБС же берет первый запрос в работу, но ещё не успевает его обработать и занести в базу, а на последующие запросы сказать «игнорируем» .

В результате могло создаться две четыре Сделки с одинаковым идентификатором amoCRM и наполнением.
Выходом из ситуации стало решение в следующем пункте.

Для исключения дублирования сделок в РБС, было решено использовать кеш сделок. В плагинах РБС, есть ограничения в хранении данных.

Техническая поддержка РБС, которая всегда приходит нам на помощь, предложила решение в виде хранения в памяти PHP и сброс кэшированных сделок в файловую систему с блокировкой. Эти варианты мы опробовали, но то, что работает в основной системе — не сработало с плагином.
В итоге единственной приемлемой системой хранения оказалась База Данных РБС, в плагине можно создать поля и хранить в них данные.

Что в итоге и решило задачу множественных запросов из amoCRM.

»На данный момент в РБС нет инструментов логирования и отладки для сторонних разработчиков (Обещают исправиться). В случае любой ошибки/недоработки приходится действовать «методом тыка» или «методом исключения». Других вариантов, к сожалению, не предусмотрено. Очень в редких вариантах можно вывести лог или дамп данных.

Иногда встречаются функции, которые есть в коде, а в документации никак не представлены. Как они работают, определять приходится опять же «методом тыка».

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