Оптовая компания ведёт продажи в CRM, а склад исполняет заказы в МойСклад. Покупатель уменьшил количество, но склад может продолжать сборку по прежнему заказу. После частичной отгрузки менеджеру приходится выяснять, сколько осталось поставить. Команда тратит время на сверки, а собственнику нужно понять, что исправить и за какую работу платить.
Эти вопросы важны и при выборе первой интеграции, и при замене действующего модуля. Можно оплатить новый обмен, когда достаточно настройки, или купить приложение и обнаружить, что обязательные операции остаются ручными. Само подключение модуля или написание кода не подтверждает, что заказ проходит так, как нужно компании.
CRMHUB помогает наладить передачу заказа от менеджера до склада. Вместе с вашей командой определяем, как должны проходить обязательные операции, сопоставляем их с готовыми решениями и настраиваем подходящий вариант. В согласованном объёме проверяем новый заказ, изменение количества, частичное исполнение и восстановление после ошибки. Если остаётся обязательное правило, которое не удалось закрыть, отдельно определяем необходимую доработку.
Работу принимаем по действиям команды: склад получает актуальное количество, менеджер видит исполненную и оставшуюся часть заказа, ответственный замечает сбой и восстанавливает обмен без незаметного повторного исполнения. Это согласованные критерии результата, которые проверяем на выбранной реализации. Карта операций и протокол показывают, что выполнено и какие ограничения остались.
На первом разговоре из вашего описания выделим главную обязательную операцию или место, где обмен расходится с работой команды. Определим, что нужно проверить до обоснования сметы на настройку или доработку. Готовое ТЗ и заполненная таблица из статьи не требуются; подробное обследование и испытания выполняются в отдельно согласованном объёме.
Три способа наладить обмен заказами
Настроить готовое приложение
Этот вариант подходит, когда нужная операция предусмотрена, а проблема связана с данными или параметрами: выбран другой склад, неверно сопоставлен товар, не определено направление изменения цены или статуса.
Например, менеджер исправляет склад в каждом новом заказе. Сначала нужно выяснить, откуда берётся это значение и какой склад должен применяться. Такая ошибка сама по себе не доказывает необходимость разработки. Если после настройки обычный заказ и исключения проходят согласованную проверку, готового решения достаточно.
Выбрать другое приложение или добавить ограниченную доработку
Второе приложение может поддерживать нужный порядок документов, но требовать другой организации учёта. Локальная доработка может закрыть отдельное правило, сохранив остальной обмен. Оба варианта требуют проверки: можно ли изменить текущую связку, кто будет отвечать за неё целиком и не начнут ли два механизма исправлять одни данные по-разному.
Разработать отдельную интеграцию
Основание — обязательное правило, которое не удаётся выполнить выбранными готовыми средствами, а ручной шаг неприемлем для компании. Нужно назвать само правило, нужные данные и наблюдаемый результат. Формулировка «у нас нестандартный бизнес» слишком широка для оценки.
МойСклад предоставляет официальный API для интеграций — способ программно обмениваться данными с сервисом. Наличие API не подтверждает реализуемость любого требования. До оценки разработки проверяют возможности обеих систем, доступ к нужным операциям и ограничения.
Как сравнить расходы и сопровождение
Цена приложения и стоимость запуска отвечают на разные вопросы. В сравнении нужны одинаковый состав операций и понятный период расходов. Конкретные суммы берут из действующих условий разработчиков и предложений исполнителей, а не из условной сметы.
Для каждого варианта выписывают:
- плату за приложение и необходимые условия использования обеих систем;
- подготовку данных, настройку, испытания и обучение;
- доработку, если она подтверждена проверкой;
- размещение собственного решения, наблюдение за ошибками и восстановление обмена;
- поддержку и изменения после обновления систем или правил компании;
- оставшиеся ручные операции и ответственных за них.
По готовому приложению важно знать, кто разбирает инцидент: разработчик модуля, настройщик или ваша команда. По собственной интеграции — где хранится код, как передаются доступы и документация, кто сопровождает решение и как проверяют изменения перед выпуском.
Обоснование выбора может звучать просто: «этот вариант покрывает наши обязательные операции; два ручных шага допустимы и закреплены за ответственным». Или: «частичное исполнение требует постоянной сверки, она неприемлема, поэтому проверяем возможность отдельной доработки». Обещать окупаемость без данных о заказах и расходах рано.
Если отдельно выбираете исполнителя, используйте критерии выбора интегратора МойСклад. Они дополняют сравнение способов реализации.
Что уже заявляют два готовых решения
Рассмотрим один поток: менеджер ведёт продажи в Битрикс24, склад работает в МойСклад. Общий порядок разделения задач описан в статье о связке МойСклад и Битрикс24. Здесь выбираем способ реализации обмена.
По состоянию на 24 октября 2026 года доступны, в частности, два приложения:
- «Интеграция с МойСклад PRO» от SM DevStudio. Разработчик заявляет передачу и обновление заказов, настройку направлений, складов, типов цен и соответствия статусов, журнал операций, повтор обработки при временных ошибках и защиту от дублей. Указано ограничение: приложение не удаляет товары, контрагентов, сделки и заказы. Остатки передаются из МойСклад в CRM.
- «МойСклад интеграция» от SiMiX. Описаны сопоставление стадий и статусов, складов и типов цен, настройка проведения и резервирования по стадиям, обмен отгрузками и реализациями, журнал с ошибками. Разработчик требует включённого складского учёта Битрикс24. Настройка нумерации относится к новым документам и не меняет прежние номера.
Это заявления в карточках разработчиков, не результаты испытаний CRMHUB. Они позволяют выбрать предмет проверки. Оба решения отмечены подпиской и встроенными покупками; актуальные платежи уточняют до выбора.
Условие о складском учёте Битрикс24 важно обсудить заранее. Если компания собиралась учитывать складские операции только в МойСклад, это отдельное решение об устройстве работы, а не формальность при установке приложения.
Сравните варианты на одном заказе
Ниже учебный сценарий, не клиентский кейс и не протокол тестирования приложений. Оптовый покупатель заказал 10 единиц товара, до сборки уменьшил количество до 8. Склад отгрузил 5, оставшиеся 3 покупатель затем отменил. Между этими действиями обмен повторно доставил уже обработанное событие.
Арифметика сценария: после изменения нужно исполнить 8; после отгрузки 5 остаётся 3; после отмены этих 3 незавершённой поставки нет. Отгруженные 5 сохраняются как совершённая операция.
Прежде чем испытывать обмен, стороны согласуют, какая система задаёт количество, цену и состояние заказа на каждом шаге. Затем один и тот же набор действий выполняют для каждого варианта в безопасных условиях. Разработку оценивают по этим же ожидаемым результатам; работающего собственного решения в примере нет.
На телефоне таблицу можно прокрутить по горизонтали, чтобы увидеть проверку второго приложения.
| Операция и ожидаемый результат | SM DevStudio PRO: что проверить | SiMiX: что проверить |
|---|---|---|
| Новый заказ: 10 единиц. В МойСклад один заказ нужного покупателя, с согласованными товаром, ценой и складом. | Передача заказов заявлена. Сверить поля и связь с исходной сделкой; исключить повторный ручной набор. | Сверить полученный документ, покупателя, количество, цену и склад. Наличие настроек не заменяет контрольного заказа. |
| Изменение до сборки: 10 → 8. Склад исполняет актуальное количество; прежнее значение не возвращается обратным обменом. | Обновление заявлено. Проверить выбранное направление и поведение после изменения количества. | Проверить передачу изменения и влияние стадии на документы и резерв. Не считать это испытанным по описанию настроек. |
| Частичная отгрузка: 5 из 8. Видны факт отгрузки 5 и неисполненные 3; заказ не считается полностью выполненным. | Проверить представление частичного исполнения в обеих системах. Общего заявления об обмене заказами недостаточно. | Обмен отгрузками заявлен. Проверить именно частичное исполнение и оставшееся количество. |
| Повтор того же события. Не возникает второго заказа или второй отгрузки; совершённое действие не удваивается. | Защита от дублей и повтор ошибок заявлены. Проверить результат при повторной доставке выбранного события. | Проверить повторную доставку и разбор ошибки по журналу. Наличие журнала не доказывает защиту от дублей. |
| Отмена неотгруженных 3. Склад больше не ждёт исполнения этих единиц; отгруженные 5 и их документы сохранены. | Удаление заказов не выполняется. Проверить, можно ли передать бизнес-отмену выбранным статусом без удаления. | Проверить согласованное поведение отмены и резерва. Сопоставление статусов само по себе не подтверждает весь сценарий. |
По каждой строке фиксируют результат, документ и оставшееся действие сотрудника. Например, для частичной отгрузки допустимым может быть ручное подтверждение менеджера перед следующим обещанием покупателю. Но собственник должен принять этот порядок: кто проверяет остаток обязательства и как замечает расхождение.
Для нового заказа ручная сверка может быть частью ограниченного старта. Для изменения количества нужно определить, кто разрешает складу продолжать работу. Для повторной доставки нельзя оставлять незаметное создание дублей: требуется устранить причину или исключить повторное исполнение контролируемым способом. Для отмены остатка назначают ответственного, который подтверждает прекращение дальнейшей отгрузки. Ручной шаг приемлем, только если он явный, выполнимый и согласован компанией.
Пробел для доработки появляется там, где обязательный результат не достигнут, настройка его не исправляет, а ручной порядок не подходит. В описании пробела должны остаться конкретная операция и ожидаемое поведение. Это позволяет оценить отдельное изменение вместо неопределённого заказа «переделать интеграцию».
Повтор события и новая покупка — разные проверки
Повторная доставка означает, что обмен ещё раз обрабатывает то же действие с тем же исходным идентификатором. Новый заказ по прошлому составу — другая покупка с новым идентификатором. Хорошая защита от дублей должна сохранить различие между ними: вторую покупку нельзя потерять как повтор первой.
В приёмке поэтому нужны оба случая. Успешное создание новой покупки не доказывает безопасную обработку повтора старого события.
Почему отмена не равна удалению заказа
В нашем примере 5 единиц уже отгружены. Покупатель отменяет оставшиеся 3. Бизнесу нужно прекратить дальнейшее исполнение и сохранить сведения о том, что уже произошло.
Ограничение SM DevStudio на удаление объектов не отвечает на весь вопрос об отмене. Возможно, согласованный процесс закрывается статусом и действиями ответственного; это проверяют. Если компания действительно требует физического удаления документа, отдельно выясняют причину и последствия для связанных операций. Такое требование нельзя незаметно подменить сменой статуса.
Возврат уже отгруженного товара — ещё одна операция. Его не следует считать выполненным лишь потому, что прошла отмена неотгруженного остатка. Если возвраты входят в обязательный процесс компании, для них добавляют отдельный сценарий и критерии приёмки.
Как принять работу CRMHUB
В рамках интеграций с МойСклад согласуем поток данных, операции и исключения, сопоставим готовые варианты и проверим выбранный путь. Если причина в параметрах или данных, предметом работ станет настройка. Если останется обязательный пробел — отдельно опишем нужное изменение и проверим техническую возможность до оценки разработки.
От компании нужен ответственный, который подтверждает правила работы: когда меняется заказ, кто разрешает отгрузку и какие ручные действия допустимы. От CRMHUB — понятное описание реализации и проверяемый результат в согласованном объёме.
Приёмка включает:
- Карту операций. Для количества, цены, склада и состояния заказа известно направление передачи и основная система.
- Протокол контрольного заказа. Обычная продажа и согласованные исключения пройдены, документы сверены, ограничения записаны.
- Обоснование выбранного варианта. Понятно, что закрывает готовое приложение, что изменили настройкой и за какую доработку предлагается платить.
- Порядок работы при ошибке. Ответственный видит сбой, понимает, кого подключить и как проверить восстановление без повторного исполнения.
- Самостоятельную работу команды. Обученный сотрудник проводит следующий контрольный заказ и знает свои действия при исключении.
Для интеграции конкретного сайта нужен такой же предметный разбор. Например, статья про Tilda и МойСклад показывает, какие данные и контрольные заказы важны именно для этой связки.
Не сработает, если обязательные правила никто не определил
Разработка не устранит спор о том, какая цена верна и кто может изменить заказ после начала сборки. Пока участники называют разный ожидаемый результат, сравнение приложений не даст однозначного ответа. Сначала нужно согласовать правило, затем выбирать реализацию.
То же относится к неподтверждённым товарам и складам. Если две системы не различают нужные позиции или сотрудник не знает, откуда должен списываться товар, новый код может перенести ту же ошибку дальше по процессу.
Вопросы перед решением о разработке
Если заказ уже передаётся, значит интеграция работает?
Подтверждён только один этап. Для компании важен весь согласованный процесс: изменение, исполнение, исключения и восстановление после ошибки. Проверять нужно то, что действительно происходит в ваших заказах.
Готовое приложение всегда дешевле собственной разработки?
Без одинакового объёма и периода сравнения ответ неизвестен. Учитывают подключение, платежи, доработки, сопровождение и ручные действия. Само название способа реализации не определяет итоговые расходы.
Можно оставить ручную проверку вместо доработки?
Да, если компания понимает её содержание, назначила ответственного и принимает такой порядок. Если шаг регулярно пропускается или не выдерживает объём заказов, это основание пересмотреть решение, а не считать процесс завершённым.