Как связать сайт, 1С, CRM и мобильное приложение

Сайт, 1С, CRM и приложение не должны хранить четыре независимые версии одного заказа. У каждого типа данных нужен основной источник, а остальные системы получают только то, что им требуется для своей работы.

Например, 1С может отвечать за товары и остатки, сайт — принимать заказ, CRM — вести общение менеджера, а приложение — показывать клиенту тот же каталог и статусы. Конкретное распределение зависит от процесса, но правило одно: сначала данные и события, потом кнопки и экраны.

Назначьте источник для каждого вида данных

Начните с простой таблицы:

Данные	Где создаются	Кому нужны
Товары, цены, остатки	1С или система учёта	Сайту и приложению
Заявка	Сайт	CRM и менеджеру
Заказ	Сайт или приложение	Учётной системе, CRM, клиенту
Статус заказа	Система обработки	Сайту и приложению
Профиль клиента	Общий сервер или согласованная система	Сайту, приложению, поддержке

Ответ «везде» создаёт расхождения. Если цену можно изменить и в CMS, и в 1С, рано или поздно покупатель увидит не ту цифру. Если статус заказа живёт только в сообщениях менеджера, приложение не сможет показать его автоматически.

Опишите события, а не абстрактную интеграцию

Для оценки нужны конкретные действия:

1. Товар или остаток изменился в 1С — когда это появится на сайте?
2. Человек оформил заказ — какие данные и куда отправляются?
3. Оплата не прошла — какой статус увидят клиент и менеджер?
4. Заказ передан в доставку — откуда приложение получит обновление?
5. CRM недоступна — заявка сохранится или потеряется?

Официальная документация модуля интернет-магазина 1С-Битрикс описывает экспорт заказов в 1С в формате CommerceML. Но реальная интеграция всё равно начинается с проверки версий, состава данных и процесса конкретной компании. Готовое название обмена не заменяет эту проверку.

Если проект начинается с магазина, подробный состав есть на странице интернет-магазина на 1С-Битрикс. Для каталога и заявок без онлайн-покупки может подойти корпоративный сайт на Битрикс.

Когда добавлять приложение

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

Если приложение действительно нужно, общий серверный слой даёт использовать один каталог, аккаунт и заказ на двух каналах. В разработку мобильного приложения входят проектирование, интерфейс, сервер и API, выпуск в App Store и Google Play, а также поддержка после запуска.

Публикацию надо учитывать в плане. Apple требует проверить приложение, заполнить точные метаданные, обеспечить доступ для проверки и соблюдать правила работы с пользовательскими данными. Google Play также обращает внимание на полное и корректное описание приложения и соответствие правилам программы.

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

Что подготовить для схемы

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

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

Источники

• Документация модуля интернет-магазина 1С-Битрикс — официальный источник по возможностям модуля и обмену заказами.
• App Review Guidelines — официальные требования Apple к проверке и данным.
• Рекомендации по публикации в Google Play — официальный справочный центр Google Play Console.