Автоматизация учёта товара в рознице: что учесть при интеграции с 1С

Учёт товара в рознице почти всегда уже ведётся в 1С. Сложности начинаются там, где эти данные должны дойти до кассы, мобильного приложения, сайта и карточек на маркетплейсах: остаток изменился в учёте, а витрина ещё сутки продаёт то, чего на складе нет. Интеграция закрывает разрыв, но работает она ровно настолько, насколько заранее решены четыре вопроса: что синхронизируем, в какую сторону, с какой частотой и что происходит, когда обмен упал.

31 августа 2026 Технологии 18 мин чтения

---

Что входит в учёт товара и что автоматизируют в первую очередь

Учёт товара в рознице держится на пяти слоях данных: справочник номенклатуры, остатки по складам и торговым точкам, цены и акционные условия, движение товара (приход, перемещение, списание, возврат) и продажи с документами. В российской рознице всё это ведётся в 1С — чаще всего в конфигурациях «Управление торговлей», «Розница» или «Комплексная автоматизация», иногда в отраслевой конфигурации под конкретный сегмент.

Поэтому под «автоматизацией учёта» бизнес обычно понимает не внедрение учётной системы с нуля — она уже работает, — а связывание её с каналами, где происходит продажа: кассой в зале, мобильным приложением, сайтом, личным кабинетом оптового покупателя и карточками на маркетплейсах. Задача интеграции в том, чтобы во всех этих точках товар назывался одинаково, стоил одинаково и числился в наличии одинаково.

Последняя строка выделяется намеренно: профиль покупателя и программа лояльности живут не в учётной системе, и попытка вести их в 1С «заодно» — частая причина, по которой проект разрастается вдвое. Разграничение зон между учётом и клиентскими данными разобрано в описании услуги интеграции приложения с CRM.

Где бизнес теряет деньги, пока витрина и учёт живут порознь

Разрыв между учётом и каналами продаж проявляется набором мелких потерь: каждая по отдельности терпима, а вместе за квартал они дают заметную сумму.

• Заказы на товар, которого нет. Покупатель оформляет позицию, менеджер перезванивает с отменой. Это не только потерянная продажа, но и испорченное впечатление — повторно такой покупатель заказывает реже.
• Ручной перенос заказов в учёт. Заявки из приложения и с сайта менеджер вбивает в 1С руками. В сезон скорость обработки падает, а вместе с ней растёт число опечаток в адресах и количествах.
• Расхождение цены между каналами. На кассе одна цена, в приложении другая, потому что прайс на витрине обновляли позавчера. Спор в торговом зале решается в пользу покупателя и за счёт маржинальности.
• Каталог, который расходится с учётом. Новая номенклатура заводится в 1С, а на витрине появляется через неделю силами контент-менеджера. Часть ассортимента не продаётся просто потому, что её не видно.
• Невозможность свести остатки по каналам. Когда офлайн-точка, приложение и маркетплейс тянут из одного физического склада без общего резерва, одна и та же единица товара продаётся дважды.

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

Карта обмена: пять групп данных, которые синхронизируют с 1С

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

Пять строк — это минимальный состав для розницы с собственным каналом продаж. Всё остальное (сертификаты к товарам, габариты и вес для расчёта доставки, серийные номера, комплекты и наборы) добавляется в ту же карту отдельными строками — и каждая строка стоит денег, поэтому список составляют осознанно, а не «выгрузим всё, потом разберёмся».

Первоисточник данных: кто владелец каждого поля

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

Распределение владельцев по умолчанию

• Остатки, цены, штрихкоды, единицы измерения. Владелец — учётная система. Витрина их только отображает, обратной записи нет.
• Маркетинговое описание, фотографии, порядок вывода в каталоге. Владелец — административная панель магазина или отдельная система управления товарным контентом. В 1С такие поля обычно ведут по остаточному принципу, и переносить их туда не нужно.
• Заказ и оплата. Создаются в канале, но после передачи главным становится документ в учётной системе: дальнейшие изменения статуса идут оттуда.
• Профиль покупателя и баланс баллов. Владелец — CRM или система лояльности, а не учётная система.

Разграничение прав на редактирование

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

Отдельно фиксируется, что происходит с товаром, которого в очередной выгрузке не оказалось: он скрывается с витрины, помечается как архивный или остаётся с нулевым остатком. Молчание по этому вопросу приводит к тому, что каталог зарастает позициями, снятыми с продажи два года назад.

Методы обмена с 1С и что выяснить до старта

Технически обмен с 1С реализуют несколькими способами, и выбор зависит от конфигурации, её состояния и объёма данных. Разница между способами — в скорости, в предсказуемости и в том, сколько работы придётся сделать на стороне учётной системы.

Вопросы к тому, кто сопровождает вашу 1С

Половину рисков проекта снимает короткий разговор до сметы. Ответы на эти вопросы стоит получить письменно:

1. Версия платформы и конфигурация — что именно установлено и когда обновлялось в последний раз.
2. Степень доработки типовой конфигурации — насколько изменены документы и регистры, есть ли собственные модули.
3. Наличие тестовой базы — можно ли отлаживать обмен на копии данных, а не на боевой системе.
4. Кто отвечает за учётную систему — штатный специалист, франчайзи или подрядчик, и в каком режиме он доступен.
5. Регламентные операции — когда идёт закрытие периода и перепроведение документов, чтобы не назначать обмен на это время.
6. Нагрузка — сколько документов в сутки проходит через систему в обычный день и в пик сезона.

Со стороны приложения и сайта обмену нужен свой договор — описание методов, форматов и правил изменения версий, чтобы обновление сервера не ломало приложения, уже установленные у покупателей. Требования к такому договору разобраны в статье о проектировании REST API.

Регламент обновления: расписание, события и очередь

Регламент обновления задают отдельно для каждой сущности из карты обмена, потому что каталог и остатки живут в разном ритме. Общая частота «раз в час на всё» обновляет справочник товаров избыточно часто, а наличие — недопустимо редко.

Расписание и события

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

Очередь, повторы и защита от задвоения

Учётная система не работает круглосуточно без перерывов: её обновляют, перезагружают, закрывают период. Значит, обмен должен переживать её недоступность без потери данных. Рабочая схема выглядит так:

• Очередь сообщений. Заказ, который не удалось передать, встаёт в очередь и уходит, когда система снова отвечает.
• Повторные попытки с нарастающим интервалом. Пять попыток подряд за секунду только добивают перегруженный сервер.
• Ключ операции. Каждый заказ передаётся с уникальным идентификатором, и повторная передача не создаёт второй документ. Без этого правила задвоенные заказы появляются в первый же сбой связи.
• Оповещение ответственного. Если очередь не разбирается дольше согласованного времени, сообщение уходит человеку, а не только в журнал.

Отдельно планируется поведение витрины в момент, когда данные устарели. Показывать последний известный остаток честнее, чем прятать товар совсем, но при оформлении заказа наличие проверяется повторно — это дешевле, чем отмена после оплаты.

Остатки по складам: резервы, мультисклад и мультигород

Остатки — наиболее чувствительная часть обмена: они меняются быстрее всего и напрямую влияют на выручку. Здесь важны четыре решения.

Резерв под оформленный заказ

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

Витринный остаток и доступный к заказу

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

Наличие по конкретным складам и точкам

Сеть с несколькими складами не может показывать одну общую цифру: покупателю важно наличие в его городе и в конкретном магазине для самовывоза. В приложении сети настольных игр Hobby Games с каталогом около 35 000 позиций эта задача решена мультизаказом: если товары корзины лежат на разных складах, корзина автоматически делится на несколько заказов, и каждый обрабатывается независимо — со своей доставкой, оплатой и промокодом.

Мультигород: свои склады и свои цены

У федеральной сети к складской логике добавляется региональная: в каждом городе свой ассортимент, свои цены и свои условия доставки. В приложении сети строительных гипермаркетов «Сатурн» с каталогом свыше 30 000 товаров привязка к городу реализована так, что заказ покупателя из Санкт-Петербурга гарантированно попадает в 1С на петербургский склад, а не на московский. Пока такая привязка не описана правилами, любой экран приложения превращается в набор частных случаев.

Омниканальный учёт: касса, приложение, сайт и маркетплейсы

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

• Касса в торговом зале. Офлайн-продажа уменьшает тот же физический остаток, что видит покупатель в приложении. Если касса выгружает продажи в учёт раз в сутки, обмен с витриной чаще этого срока смысла не имеет — узкое место находится не там, где его ищут.
• Мобильное приложение. Добавляет сценарии, которых нет на сайте: сканер штрихкода прямо в зале, наличие в ближайшем магазине, бонусная карта вместо пластиковой. В приложении сети гипермаркетов «Европа Маркет», которым пользуются 149 839 человек, сканер и умный поиск с исправлением опечаток работают на данных учётной системы.
• Сайт интернет-магазина. Требует того же обмена, что и приложение. Когда сайт и приложение сделаны на одной кодовой базе, обмен настраивается один раз на оба канала — эта модель описана на странице разработки сайта и приложения на единой базе.
• Маркетплейсы. Wildberries, Ozon и Яндекс Маркет забирают из учёта товарный фид, остатки и цены, а возвращают заказы. При работе со своего склада остатки на площадках нужно уменьшать одновременно с собственной витриной, иначе штрафы за отмену прилетают от площадки.
• Оптовый канал. Юридическим лицам нужны свои виды цен, отсрочка и документы. Это отдельный контур обмена — состав работ описан на странице B2B-приложений для продаж юридическим лицам.

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

• RetailCRM — обработка заказов и единая карточка покупателя.
• Mindbox — сегментация, рассылки и маркетинговая автоматизация.
• Maxma — программа лояльности с гибкими механиками начисления и списания.
• Retail Rocket — товарные рекомендации на витрине и в письмах.

Разбор одной такой связки с передачей событий приложения в маркетинговую систему — в статье об интеграции Mindbox с кастомными событиями.

Маркировка и прослеживаемость: что добавляется к обмену

Для части товарных категорий к обычному учёту добавляется обязательная прослеживаемость. Обувь, одежда, парфюмерия, молочная продукция, лекарства и ряд других групп продаются с кодами маркировки системы «Честный ЗНАК»; для алкоголя действует ЕГАИС, для продукции животного происхождения — «Меркурий».

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

Но три требования в проект интеграции добавить придётся:

• Признак маркированной позиции в карточке. Он нужен, чтобы правильно строить сценарий сборки и отгрузки заказа, а также ограничивать частичные возвраты по таким товарам.
• Учёт на уровне экземпляра, а не только количества. Для маркированных категорий склад оперирует конкретными кодами, поэтому резерв и отгрузка описываются точнее, чем «минус одна штука».
• Возрастные и отраслевые ограничения на витрине. Категории с ограничением по возрасту требуют отдельного поведения каталога — например, в приложении сети «Мосигра» карточки товаров 18+ скрываются размытием для неавторизованных и несовершеннолетних пользователей.

Отраслевой пример с самыми жёсткими требованиями к учёту — аптечная розница с рецептурным отпуском и маркировкой каждой упаковки, разобранный в статье о приложении для аптеки.

Десять ошибок при интеграции с 1С

Ошибки в таких проектах повторяются от компании к компании, и почти все они относятся к постановке задачи, а не к программированию.

1. Начать с разработки, а не с карты данных. Пока не описано, какие сущности и в какую сторону передаются, смета считается диапазоном, а приёмка превращается в спор.
2. Сделать обмен двусторонним там, где нужен односторонний. Цены и остатки идут только из учётной системы. Возможность править их на витрине почти всегда лишняя и почти всегда приводит к расхождению.
3. Назначить один регламент на все сущности. Каталог и остатки живут в разном ритме, и общая частота обмена вредит обоим.
4. Не предусмотреть очередь и повторные попытки. Первая же плановая перезагрузка учётной системы оборачивается потерянными заказами.
5. Забыть ключ операции. Повторная передача заказа создаёт второй документ, склад комплектует два одинаковых заказа, покупатель получает две доставки.
6. Проверять обмен на выгрузке из десяти товаров. Каталог на 30 000 позиций ведёт себя иначе: всплывают время выгрузки, дубли артикулов, товары без категории и позиции с пустыми характеристиками.
7. Не учесть доработки типовой конфигурации. Если документы и регистры изменены под компанию, стандартный обмен потребует доработки — и узнать об этом лучше до подписания договора.
8. Не назначить владельца обмена со стороны бизнеса. Нужен сотрудник, который принимает решения по данным: он отвечает за правила и разбирает расхождения после запуска.
9. Игнорировать резервы. Остатки без резерва под оформленные заказы дают перепродажу в первый же день распродажи.
10. Не поставить наблюдение за обменом. Пока о сбое сообщает покупатель, а не система мониторинга, каждая остановка обмена стоит суток продаж.

Порядок внедрения: шесть шагов от карты данных до приёмки

Порядок работ одинаков и для нового магазина, и для действующего проекта, который переводят на нормальный обмен. Меняется только объём внутри шагов.

1. Шаг 1 · Карта данных и методов обмена. Составляется таблица сущностей с направлением, частотой и владельцем каждого поля, а параллельно выясняется, что именно умеет отдавать и принимать учётная система.
2. Шаг 2 · Договор об обмене и доступ к тестовой базе. Фиксируются форматы, состав методов, правила изменения версий и порядок обработки ошибок. Отладка идёт на копии данных, а не на боевой системе.
3. Шаг 3 · Настройка двустороннего обмена. Из учётной системы уходят каталог, остатки и цены, обратно возвращаются заказы, оплаты, данные покупателя и резервы.
4. Шаг 4 · Регламент обновления и события. Задаются расписание массовых операций, событийные обновления, очередь, повторные попытки и оповещения ответственных.
5. Шаг 5 · Проверка на боевых данных. Сценарии прогоняются на полном каталоге: выгрузка номенклатуры, изменение цены и остатка, оформление заказа, резерв, возврат статуса и отгрузки.
6. Шаг 6 · Запуск с параллельным периодом. Первые недели обмен работает под ежедневной сверкой, и только после совпадения данных ручные операции прекращаются.

Для магазина на платформе FITTIN обмен с 1С входит в базовый набор модулей и настраивается под конфигурацию конкретной учётной системы. Платформа устроена как конструктор: любой из модулей можно доработать под сценарий, которого нет в стандартном наборе, — например, под региональные цены или отраслевую логику склада. Для действующего проекта, сделанного другой командой, работа начинается с разбора текущего стека — этим занимается аудит мобильного приложения от 7 дней.

Как проверить, что обмен работает

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

• Задержка обновления остатка. Сколько минут проходит между изменением наличия в учёте и его появлением на витрине. Целевое значение задаётся по категориям.
• Доля заказов, дошедших до учётной системы без ручных правок. Показатель, по которому видно реальное качество обмена, а не декларируемое.
• Число расхождений при сверке. Регулярное сравнение остатков и цен между системами по случайной выборке позиций.
• Доля отмен с причиной «нет в наличии». Прямая денежная метрика: она падает, когда обмен настроен, и растёт при первых сбоях.
• Время восстановления после сбоя. Сколько занимает разбор очереди и возврат данных в согласованное состояние.

Практическое дополнение — журнал обмена, доступный не только разработчику. Когда сотрудник электронной коммерции может сам посмотреть, ушёл ли конкретный заказ в учёт и когда последний раз обновлялись цены, число обращений в поддержку снижается в разы.

Сколько стоит автоматизация учёта и от чего зависит смета

Стоимость интеграции складывается из объёма обмена и из состояния системы, к которой подключаются. Одинаковый по описанию проект в двух компаниях легко различается вдвое, если в одной стоит типовая конфигурация, а в другой — переписанная под себя за десять лет.

Модель расчёта на платформе

Модель сотрудничества состоит из трёх частей: единоразовая интеграция платформы под бренд, ежемесячная лицензия с включённой поддержкой команды и доработки нового функционала по Time & Materials — со сметой и оценкой по часам перед стартом задачи. Обмен с 1С входит в базовый набор модулей, поэтому в большинстве проектов он попадает в первую часть, а не в доработки. Составы пакетов и действующие цифры опубликованы на странице тарифов.

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

Семь факторов, которые двигают смету

• Состояние методов обмена в учётной системе. Готовые опубликованные сервисы — один объём работ, отсутствие любых методов — другой.
• Число сущностей в карте обмена. Каталог, остатки, цены, заказы и статусы — базовый набор; сертификаты, габариты, комплекты и серийные номера добавляются сверху.
• Объём каталога. Тридцать тысяч позиций требуют пакетной выгрузки, индексации поиска и отдельного внимания к скорости витрины.
• Число складов и городов. Мультисклад и региональные цены — это отдельная логика, а не настройка галочкой.
• Требования к частоте обновления. Обмен раз в сутки и обмен раз в пять минут — разные по трудоёмкости решения.
• Степень доработки конфигурации 1С. Нетиповые документы и регистры почти всегда означают работы на стороне учётной системы.
• Отраслевые требования. Маркировка, ЕГАИС, рецептурный отпуск и оптовый документооборот расширяют состав обмена.

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

Кейсы: проекты с большим каталогом и обменом с 1С

Показательнее всего интеграция выглядит там, где каталог большой, а складов много. Цифры приведены со страниц кейсов.

В «Европа Маркет» обмен с учётной системой обслуживает продуктовый каталог сети гипермаркетов: наличие по конкретным магазинам, умный поиск с исправлением опечаток и сканер штрихкода в зале — приложением пользуются 149 839 человек. В Hobby Games каталог около 35 000 позиций и распределённое наличие закрыты мультизаказом с автоматическим делением корзины по складам. В Gulliver Market данные учётной системы работают вместе с персонализацией витрины: на приложение приходится 50% дохода ритейлера и 80% мобильного трафика бренда. В DAISYKNIT обмен с 1С и маркетинговой системой переносили со стороннего решения — клиентская база и интеграции сохранились полностью, кейс номинирован на Workspace Digital Awards 2026.

Остальные проекты собраны в разделе кейсов. Отраслевые сценарии описаны на страницах приложений для магазинов товаров для дома и ремонта и приложений для продуктовых магазинов.

Итог: чек-лист перед стартом интеграции

Автоматизация учёта в рознице упирается в шесть решений, которые принимает бизнес. Когда они приняты письменно и до старта работ, проект идёт предсказуемо:

1. Составьте карту обмена. Сущность, направление, частота, что ломается без неё — четыре колонки на одном листе.
2. Назначьте владельца каждому полю. Одно поле — одна система, которая имеет право его менять.
3. Разделите расписание и события. Каталог по расписанию, остатки и заказы по событию, ночная сверка отдельно.
4. Заложите очередь, повторы и ключ операции. Обмен обязан переживать недоступность учётной системы без потерь и задвоений.
5. Опишите работу с остатками полностью. Резерв, страховой буфер, наличие по складам и правило для позиций, пропавших из выгрузки.
6. Поставьте наблюдение и регламент сверки. О сбое должна сообщать система мониторинга, а не покупатель в отзыве.

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

Что делать дальше:

• Оценить бюджет и срок под свой сценарий — калькулятор стоимости или сравнение тарифов.
• Разобрать обмен для действующего продукта — аудит кода; зафиксировать состав работ документом — разработка технического задания.
• Подключить обмен к новому каналу продаж — ERP-интеграция для интернет-магазина, приложение для интернет-магазина или обсуждение проекта с командой.

Часто задаваемые вопросы

Как интегрировать мобильное приложение интернет-магазина с 1С?

Обмен идёт через методы, которые доступны на стороне учётной системы: типовой обмен по формату EnterpriseData, опубликованные HTTP-сервисы, файловый обмен или готовый коннектор. Сначала составляется карта данных — какие сущности синхронизируются и в какую сторону, — затем настраивается двусторонний обмен: из 1С уходят каталог, остатки и цены, обратно возвращаются заказы, оплаты, данные покупателя и резервы. Обновление работает по расписанию для массовых операций и по событию для заказов и статусов. На платформе FITTIN модуль обмена с 1С входит в базовый набор и настраивается под конфигурацию конкретной компании.

Как часто нужно обновлять остатки из учётной системы?

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

Можно ли связать 1С с приложением, если конфигурация доработана под нашу компанию?

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

Что происходит с заказами, если 1С недоступна во время обмена?

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

Чем интеграция с 1С отличается от интеграции с CRM?

Разные предметы обмена. С учётной системой синхронизируются товар, остатки, цены, заказы и статусы — это данные о товародвижении. С CRM и системой лояльности — профиль покупателя, история покупок, сегменты, баллы и коммуникации. Смешивать контуры не стоит: попытка вести клиентскую базу и бонусные механики в 1С заметно увеличивает объём работ и усложняет дальнейшее развитие. В большинстве проектов оба обмена настраиваются параллельно, состав второго описан на странице интеграции приложения с CRM.

Нужен ли обмен с 1С, если магазин работает на готовой платформе?

Нужен, и обычно он уже предусмотрен. На платформе FITTIN модуль обмена с учётной системой входит в базовый набор, а работа сводится к настройке под конфигурацию компании: состав сущностей, регламент обновления, правила по складам и ценам. Уникальные сценарии — региональные цены, отраслевая логика склада, нестандартные документы — добавляются доработкой соответствующего модуля. Готовая платформа экономит не сам обмен, а время на его реализацию с нуля.

Сколько стоит интеграция приложения с 1С?

Стоимость зависит от семи факторов: состояния методов обмена в учётной системе, числа синхронизируемых сущностей, объёма каталога, количества складов и городов, требуемой частоты обновления, степени доработки конфигурации и отраслевых требований вроде маркировки. На платформе обмен с 1С входит в единоразовый пакет интеграции под бренд, поддержка и обновления модулей включены в ежемесячную лицензию, а доработки сверх базового набора считаются по фактически отработанным часам со сметой перед стартом задачи. Действующие цифры опубликованы на странице тарифов, ориентировочный бюджет под сценарий считает калькулятор.

Можно ли передать сопровождение интеграции другому подрядчику?

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

Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.