Как управлять несколькими магазинами и юрлицами на маркетплейсах

Дата проверки информации: 21 июля 2026 года.

Когда у компании несколько магазинов, кабинетов и юридических лиц, проблема обычно не в количестве вкладок. Главный риск — смешать товары, остатки, цены, доступы и деньги так, что заказ уйдёт не со склада, расход попадёт не в ту организацию, а общий P&L скроет убыточный кабинет.

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

Короткий ответ: что объединять, а что разделять

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

Когда компании нужен мультиаккаунт

• один бренд продаёт через несколько ИП или ООО;
• есть отдельные кабинеты Wildberries, Ozon, Яндекс Маркета и других площадок;
• разные магазины работают по FBO и FBS;
• несколько брендов или направлений обслуживает одна команда;
• агентство или управляющая компания ведёт кабинеты клиентов;
• каталог общий, а цены, налоги и остатки отличаются;
• владелец хочет общий P&L, но бухгалтерия закрывает каждое юрлицо отдельно.

Правило № 1: кабинет принадлежит конкретной организации

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

У Яндекс Маркета пользователь может иметь доступ к нескольким кабинетам и магазинам, а владелец регулирует права. Но это управление доступом, а не смешение договоров и расчётов.

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

Архитектура: семь сущностей, которые нельзя путать

1. Организация

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

2. Договор и кабинет площадки

Связывает организацию с маркетплейсом, тарифами, выплатами, документами и API-доступом.

3. Магазин

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

4. Склад

FBO-склад площадки, FBS-склад продавца, фулфилмент или собственное место хранения. Важно знать владельца товара и источник доступного остатка.

5. Товар и предложение

Одна мастер-карточка может иметь несколько предложений, артикулов и цен на площадках. Нужна таблица соответствий, а не связь по названию.

6. Заказ и финансовая операция

Заказ относится к конкретному магазину и юрлицу. Комиссия, логистика, реклама и выплата должны наследовать этот контекст.

7. Пользователь и роль

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

Модель источников правды

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

Как организовать общий каталог

Единый каталог полезен для повторного использования характеристик, фотографий и описаний, но предложение на площадке должно сохранять свой контекст. Минимальная схема:

• внутренний SKU и вариант товара;
• бренд и правообладатель;
• организация-продавец;
• кабинет и магазин;
• артикул продавца и ID площадки;
• цена, НДС и минимальная маржа;
• источник остатка;
• статус карточки и ограничения категории.

SelSup может выступать PIM-контуром: создать карточку один раз, адаптировать обязательные характеристики для площадок и сохранить соответствия. Подробнее — в статье о PIM-системе для маркетплейсов.

Как не продать одну единицу дважды

Общий FBS-остаток нескольких магазинов требует центрального резерва. Типичный безопасный процесс:

1. заказ поступает с площадки с ID кабинета и магазина;
2. система проверяет доступный остаток нужной организации и склада;
3. единица резервируется атомарно;
4. на остальные каналы передаётся новый доступный остаток;
5. отмена снимает резерв по согласованному статусу;
6. ошибка синхронизации попадает в журнал и уведомление.

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

Цены и акции для нескольких кабинетов

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

• минимальная цена по организации и каналу;
• целевая маржа;
• допустимая скидка;
• право площадки или менеджера менять цену;
• реакция на акцию;
• округление и расписание;
• лимит автоматического изменения;
• журнал и откат.

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

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

Ролевая модель доступа

Wildberries и Яндекс Маркет предоставляют собственные механизмы пользователей и прав. Во внешней системе права не должны быть шире, чем на площадке. Используйте отдельные учётные записи, минимальные разрешения и регулярный отзыв доступа у уволенных сотрудников.

Финансовая аналитика: два вида P&L

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

Консолидированный P&L нужен владельцу группы. Он суммирует сопоставимые статьи, но не отменяет раздельный учёт. В нём отдельно показывают:

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

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

Связка с 1С

Для нескольких организаций заранее определите:

• какая организация и договор соответствуют кабинету;
• как сопоставляется номенклатура;
• какой склад используется для FBS;
• какие документы создаются по продаже, возврату и услуге;
• как загружаются отчёты комиссионера/агента;
• как исправляются поздние корректировки;
• кто подтверждает проведение документов;
• как тестируется обновление интеграции.

Подробная архитектура — в статье об интеграции 1С с маркетплейсами.

План внедрения по этапам

Этап 1. Инвентаризация

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

Этап 2. Матрица данных

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

Этап 3. Права

Опишите роли и выдайте минимальные доступы. Не подключайте общий личный номер или одну учётную запись для всей команды.

Этап 4. Пилот

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

Этап 5. Финансовая сверка

Закройте контрольный период и сверьте строки отчёта, выплаты и документы. Методика описана в статье о сверке отчётов маркетплейсов.

Этап 6. Масштабирование

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

Ежедневная панель руководителя

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

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

Типичные ошибки

Одна учётная запись для всей команды

Невозможно доказать, кто изменил цену или выгрузил отчёт. Используйте персональные доступы.

Общий остаток без владельца товара

Система обещает товар не той организации. Храните организацию и склад в каждой записи.

Связь товаров по названию

Названия меняются и повторяются. Нужен внутренний SKU и таблица идентификаторов площадок.

Одинаковая цена во всех магазинах

Разная экономика делает общий порог опасным. Считайте минимальную маржу по контуру.

Общая аналитика без возможности раскрытия

Сводная цифра должна раскрываться до первичной операции и юрлица.

Автоматизация сразу всех кабинетов

Ошибка правила размножается. Начинайте с пилота и проверяйте негативные сценарии.

FAQ

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

Да, если сервис хранит их раздельно, соблюдает права и позволяет консолидировать аналитику без смешения документов и остатков.

Можно ли перенести кабинет Wildberries на другое юрлицо?

По официальной справке Wildberries передать права владельца можно другому пользователю, но сам магазин закреплён за ИНН и не передаётся другому юрлицу.

Нужна ли отдельная 1С для каждого юрлица?

Это зависит от конфигурации и учётной политики. Важно, чтобы документы, организации, склады и взаиморасчёты были однозначно разделены. Решение согласуйте с вашим специалистом 1С и бухгалтером.

Как объединить аналитику и не смешать деньги?

Стройте сводный слой поверх раздельных данных. Любая метрика должна иметь измерения «организация, кабинет, магазин, площадка, SKU».

Можно ли ИИ-агенту работать со всеми магазинами?

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

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