Короткий ответ: что именно нужно связать
Простыми словами, 1С хранит данные, с которыми работает бизнес, приложение показывает покупателю нужную часть этих данных, а сервер между ними передаёт изменения и заказы. API — согласованный способ, которым программы запрашивают данные и сообщают друг другу об изменениях. Например, сервер получает обновлённый остаток, показывает его в приложении и передаёт новый заказ в учётный контур. Покупателю не приходится разбираться, где находится 1С.
Обычно путь выглядит так: приложение → сервер приложения → 1С. Это не единственно возможная схема, но она позволяет не хранить доступ к учётной системе в телефоне и отдельно решать, что делать при задержке обмена. Прежде чем выбирать готовый модуль или писать свой API, мы выясняем, какая именно программа 1С и версия установлены, где она размещена и какие данные действительно нужны приложению.
Быстрая проверка: возьмите один товар и один заказ. Кто меняет цену, где виден остаток, куда попадает заказ и что увидит покупатель, если 1С не ответит? Эти четыре ответа полезнее общего требования «сделать интеграцию».
Как мы связали приложение, админ-панель и 1С в «Бакаеве»
У «Бакаева» уже были магазины и учёт в локальной 1С. Для доставки понадобились приложение покупателя и рабочая панель команды. Мы помогли перенести 1С в облако, подключили специалиста по 1С и настроили двусторонний обмен между учётной системой и админ-панелью через API. Это не отдельная кнопка «синхронизировать», а связь частей одного магазина.
Что проходит через обмен: карточки товаров, остатки, изображения и другие данные магазина. В каталоге больше 10 000 товаров. Правки из админ-панели передаются в 1С, а изменения на стороне 1С возвращаются в магазин. Покупатель выбирает продукты в приложении и видит статус доставки; команда в админ-панели работает с заказами и курьерами.
Реальный проект 13FOX
«Бакаев»: каталог и 1С работают вместе
На экране — админ-панель магазина. Из неё команда управляет товарами; данные синхронизируются с облачной 1С.
Этот проект показывает, что связать собственное приложение с 1С реально даже тогда, когда исходная база стоит локально, а товаров много. Способ реализации выбирают по конфигурации и процессам: не каждому магазину нужен перенос в облако или такой же объём функций.
Как данные ходят между приложением и 1С
Из учёта к покупателю. Товар, цена или остаток меняются в системе, которая за них отвечает. Сервер получает изменения, приводит их к виду для каталога, а приложение показывает обновлённые данные. Изображения можно передавать одним ритмом, остатки — другим: скорость зависит от того, насколько опасна задержка для покупателя.
От покупателя к команде. Человек оформляет заказ. Сервер принимает его, сохраняет свой номер и передаёт сведения в рабочую систему магазина и при необходимости в 1С. Когда заказ подтверждён или меняет статус, приложение показывает результат. Путь конкретного заказа согласуют до разработки: в одних процессах сначала нужен резерв, в других оплата или подтверждение сотрудника.
Между админ-панелью и 1С. В «Бакаеве» обмен работает в обе стороны: изменение в панели попадает в 1С, изменение в 1С возвращается в магазин. Это не означает, что любое поле можно без правил переписывать с двух сторон. Нужно заранее определить, кто отвечает за цену, остаток, описание товара и статус заказа.
Кто отвечает за цену, остаток и статус
Даже при обмене в обе стороны каждой цифре нужен хозяин. Если цену одновременно поправили в админ-панели и в 1С, какую из них увидит покупатель? Решение принимают заранее: кто меняет цену, кто ведёт остаток и где подтверждается заказ. Таблица ниже — пример вопросов для проекта, а не описание внутренней настройки «Бакаева». ID в таблице — постоянный номер записи, по которому системы узнают один и тот же товар или заказ.
| Данные | Кто задаёт значение | Что получает приложение | Проверка |
|---|---|---|---|
| Товар и вариант | 1С или админ-панель — выбрать | Название, единицу, фото, внешний ID | Не склеить разные варианты |
| Цена и акция | Владелец каждого правила отдельно | Цена для конкретной корзины | Повторная проверка до оплаты |
| Остаток | Учёт по складу и резерву | Доступность с понятной задержкой | Последняя единица и два заказа |
| Заказ и статус | Сервер принимает, 1С подтверждает учёт | Принят, подтверждён, собирается | Один ID, отказ и повтор |
В карте обмена рядом с каждым видом данных нужны ещё четыре ответа: куда передавать, когда, по какому номеру узнавать запись и кто разбирает ошибку. Одного артикула часто мало: у товара бывают разные размеры, упаковки и склады. После первой сверки системы сохраняют номера одной и той же записи, чтобы не перепутать её при следующем обмене.
Каталог и остатки: где нужна скорость, а где нет
Сначала в приложение передают весь каталог: товары, варианты, единицы измерения, категории и изображения. Затем разумнее пересылать только то, что изменилось. На масштабе каталога вроде «Бакаева» это особенно важно: не нужно заново загружать тысячи карточек из-за одной новой цены. При этом время от времени системы сверяют весь список, чтобы удалённый или объединённый товар не остался в приложении.
Цена, доступность и фото живут в разных ритмах. Изображение обычно спокойно переносит задержку, а наличие последней единицы товара — нет. Поэтому у каждой группы данных записывают допустимую задержку и действие при просрочке. Если каталог обновился утром, но склад не подтвердил остаток при оформлении, приложение не должно обещать покупателю гарантированную доставку.
Особенно внимательно проверяйте единицы и варианты: «1 упаковка» в приложении не равна «1 штуке» в 1С. Товар с несколькими фасовками, цветами или складами требует устойчивых идентификаторов для каждого продаваемого варианта. Там, где покупатель может собирать корзину без сети, локальное состояние нужно повторно проверять при отправке заказа. Офлайн-корзина удобна, но не является подтверждением цены или резерва.
Путь одного заказа: от кнопки до учёта
Допустим, покупатель нажал «Оформить». Сервер приложения создаёт заказ со своим постоянным ID и ключом повтора. До передачи в 1С он проверяет состав корзины и актуальность условий покупки. Если цена или наличие изменились, человек должен увидеть новое условие и подтвердить его; молчаливо подменять сумму нельзя.
- Приём: сервер сохраняет заказ и сообщает, что заявка получена. Это ещё не означает, что 1С подтвердила наличие или резерв, если он предусмотрен.
- Передача: модуль обмена находит те же товары и покупателя в 1С, отправляет данные и сохраняет результат операции.
- Подтверждение: 1С возвращает свой ID или документ, а сервер связывает его с исходным заказом и обновляет статус в приложении.
- Сверка: если ответ пропал, сервер ищет результат по постоянному ключу и лишь затем повторяет безопасную операцию. Ошибки попадают в журнал и к ответственному.
На этапе оплаты порядок может быть иным: резерв до списания денег, авторизация платежа до подтверждения склада или оплата после сборки. Здесь нет универсального правильного сценария. Его выбирают вместе с бизнесом и платёжной системой, а затем проверяют отмену, возврат и частичную сборку.
Что записать в техническом задании
Хорошее техническое задание начинается не со списка команд для программиста, а с ответов на бизнес-вопросы. Для каждого вида данных запишите нужные поля, ответственного, направление, момент передачи, допустимую задержку и действие при ошибке. Тогда разработчик приложения и специалист 1С не будут по-разному трактовать слово «синхронизация».
Для одного заказа минимальный договор обычно включает ID на стороне приложения, ID или ссылку на документ 1С, дату и состояние, позиции с идентификаторами вариантов, единицы и количество, итоговую сумму, доставку и согласованные данные покупателя. Отдельно опишите, какие поля можно изменить после создания заказа и кто уведомит другую сторону об изменении. Состав зависит от процесса: в продуктовом магазине важно допустить замену позиции при сборке, в продаже цифровой услуги — совсем другой набор событий.
К этому договору приложите не только успешный ответ API, но и примеры отказа: неизвестный товар, недостаточный остаток, изменившаяся цена, конфликт клиента, повтор одного заказа. Для каждого примера нужен видимый статус в приложении, запись для сотрудника и условие восстановления. Именно эти примеры затем становятся сценариями приёмки.
Штатный обмен, API или отдельный сервер?
Способов несколько. Платформа 1С умеет обмениваться данными через файлы и программные интерфейсы. Можно использовать штатное мобильное решение, подключить готовый модуль или настроить собственный обмен через API. Выбор зависит от задачи и конкретной программы 1С: возможность платформы ещё не означает, что нужный способ доступен в вашей базе и с вашими правами.
| Подход | Когда уместен | Что проверить |
|---|---|---|
| Штатное мобильное решение 1С | Типовой сценарий сотрудника, который решение уже покрывает | Какую именно 1С и версию используют |
| Готовый обмен или модуль | Обычные товары и заказы без сложных правил | Направления, конфликты, журнал ошибок и поддержку обновлений |
| Свой сервер и модуль обмена с 1С | Несколько каналов продаж, особые цены, доставка, нагрузка или сложные статусы | Правила данных, права доступа, повторы после сбоя и сопровождение |
Мы выбрали для «Бакаева» связку админ-панели с 1С через API: нужно было объединить каталог, онлайн-заказы и доставку, а не просто открыть сотруднику типовой экран 1С. Для другого проекта готового обмена может хватить. Если нужен свой сервер, он хранит ключи доступа и отдаёт телефону только то, что нужно покупателю. Если у вас 1С:Фреш, доступные интерфейсы и права нужно проверить отдельно.
Права и доступ: что не должно попасть на телефон
Покупательскому приложению не нужны учётные данные 1С и прямой доступ к внутренним справочникам. Если интеграция идёт через сервер приложения, он проверяет пользователя, ограничивает набор доступных данных и вызывает 1С от имени отдельной технической роли с минимально нужными правами. Канал связи защищают, секреты хранят вне приложения, а действия по заказу записывают так, чтобы можно было восстановить причину расхождения.
Журнал полезен только при разумном составе данных: ID операции, время, система-источник, результат, код ошибки и номер попытки. Полные персональные данные и платёжные реквизиты в технический журнал без необходимости копировать не нужно. Перед запуском проверьте, кто имеет доступ к журналам и сколько они хранятся; конкретные сроки определяются требованиями проекта.
Что делать, когда 1С не отвечает
Самая опасная ошибка не всегда выглядит как красный экран. Сервер отправил заказ, 1С его записала, но подтверждение потерялось. Приложение считает, что заказ не создан, и отправляет его ещё раз. Если у операции нет устойчивого ключа, в учёте окажутся два заказа.
Поэтому при проектировании обмена мы предусматриваем защиту от дублей: повторный запрос с тем же номером не должен создавать второй заказ. Сервер сохраняет номер заказа, связь с записью в 1С и результат попытки. Если ответа нет, он сначала проверяет, появился ли заказ в учётной системе, и только затем решает, можно ли отправить его ещё раз. Пока подтверждения нет, покупатель видит честный промежуточный статус, например «Заказ принят, подтверждаем наличие».
Отдельно измеряют задержку обмена, число неподтверждённых заказов и возраст самой старой ошибки. Эти показатели нужны не для красивого отчёта, а чтобы сотрудник заметил проблему до звонка недовольного покупателя.
Если вы ещё выбираете, нужен ли магазину отдельный канал в телефоне, начните с нашего материала о приложении интернет-магазина. Здесь мы разбираем уже следующий вопрос: как его связать с 1С.
Пробный запуск: что проверить до полного запуска
Начните не со всего каталога, а с одного сквозного маршрута. Пусть 1С-специалист, разработчик и человек, который обрабатывает заказы, вместе пройдут пять случаев:
- Обычный заказ: товар, вариант, цена, заказ и статус совпали.
- Последняя единица товара: два клиента оформляют её почти одновременно; приложение показывает корректный итог.
- Цена изменилась после добавления в корзину: покупатель видит новое условие до оплаты.
- 1С недоступна или ответ потерян: заказ остаётся видимым, повтор не создаёт дубль.
- Частичная сборка, отмена или возврат: статусы и суммы не расходятся между системами.
Приёмка — это не фраза «данные синхронизируются». Нужны контрольные ID, запись результата по каждому случаю, ответственный за ошибки и способ ручной сверки. После пробного запуска можно оценивать полный каталог, расписание обновлений и сопровождение. Основные факторы стоимости — число видов данных и правил, нестандартность конфигурации, количество складов, объём данных, требования к задержке и отказоустойчивости.
Частые вопросы
Можно ли подключить мобильное приложение напрямую к 1С?
Технически способ зависит от конфигурации и опубликованного интерфейса. Для клиентского приложения обычно разумнее использовать свой сервер: он хранит правила доступа, связывает данные и обрабатывает недоступность 1С.
Что синхронизировать в первую очередь?
Для заказа обычно нужны товар и вариант, цена, доступность, клиент, состав заказа и статусы. Владельца, направление и допустимую задержку назначают каждому полю отдельно.
Нужен ли обмен в реальном времени?
Там, где задержка меняет решение покупателя, проверка должна быть ближе к моменту действия. Каталог и изображения часто можно обновлять пакетно. Конкретный режим определяют по запасу, нагрузке и цене ошибки.
Подойдёт ли типовой обмен или 1С:Фреш?
Это выясняют по точной конфигурации, версии, модели размещения и правам на нужные операции. Поддержка механизма платформой не означает, что он открыт в конкретной базе.
Как принять интеграцию перед запуском?
Проверьте обычный заказ, изменение цены и остатка, отказ 1С, повтор после тайм-аута, частичную обработку и сверку статусов. Один повтор не должен создавать второй заказ.
На что мы опирались
- 1С: интеграционные возможности платформы.
- 1С: синхронизация в библиотеке стандартных подсистем.
- 1С: условия синхронизации штатного мобильного решения «1С:Заказы».
Если кроме приложения у вас есть CRM, отдельно прочитайте как не получить две версии заказа при связи Битрикс24 и 1С.
Разберём карту обмена на одном заказе
Назовите точную конфигурацию и размещение 1С, покажите путь одного заказа и перечислите данные, которые должны видеть покупатель и сотрудники. Мы определим владельцев полей, способ связи и сценарии приёмки — так будет ясно, нужен ли готовый обмен или отдельная разработка.
Доступы и пароли для первого разговора не нужны.