Работа в нескольких городах добавляет к интеграции региональный слой: разные юрлица, склады, цены и часовые пояса. В JSON API МойСклад это решается через организации, точки продаж, типы цен и внимательную работу с датами. Разберём практические нюансы для Москвы, СПб и других регионов.
Региональная модель данных
Регион в МойСклад — не отдельная сущность, а комбинация организаций, складов и точек продаж. Мультирегиональный бизнес обычно моделируют так:
- Организации (
organization) — юрлица, если в регионах разные ИП/ООО; - Склады (
store) — по одному или несколько на город; - Точки продаж (
retailstore) — привязаны к складу и организации; - Типы цен (
pricetype) — например, «Розница Москва» и «Розница СПб».
Заказ или продажа несёт ссылки на конкретные организацию и склад, поэтому по документу всегда однозначно определяется регион. Это удобно для сервисных страниц вида «настройка X в Москве / СПб»: фильтр по store или organization даёт региональный срез.
Часовой пояс и даты в API
Самый коварный региональный нюанс — время. Все даты в JSON API 1.2 передаются в формате yyyy-MM-dd HH:mm:ss по часовому поясу аккаунта, без указания зоны. Это значит, что московский аккаунт всегда отдаёт московское время, даже если склад физически во Владивостоке.
Практические следствия для разработчика:
- нельзя трактовать дату из API как UTC — нужно знать часовой пояс аккаунта;
- фильтры
momentиupdatedработают в этом же поясе; - при выгрузке на сайт с другим TZ время конвертируют явно.
Региональные цены
Разные города — часто разные цены. В МойСклад это решается типами цен: у номенклатуры есть массив salePrices, где каждый элемент связан с priceType. Один товар одновременно хранит цену для Москвы, СПб и опта.
При интеграции с сайтом важно выбирать нужный тип цены под регион пользователя:
| Тип цены | Регион | Где применяется |
|---|---|---|
| Розница Москва | Москва | Сайт для МСК |
| Розница СПб | Санкт-Петербург | Сайт для СПб |
| Оптовая | Все | B2B-портал |
Тип цены выбирается по href из priceType, а не по названию: названия можно переименовать, а идентификатор стабилен. Значения цен — по-прежнему в копейках.
Налоги и юрлица по регионам
Если в регионах работают разные юрлица, у них могут отличаться система налогообложения и реквизиты. В МойСклад налоговый режим и настройки НДС задаются на уровне организации organization, поэтому регион фактически определяет и налоговую логику документа.
- у каждой организации свой ИНН, КПП и режим налогообложения;
- ставка НДС позиции (
vat) должна соответствовать режиму организации-продавца; - для УСН НДС в позициях не выделяется — это надо учитывать при формировании чека и документов.
Адреса, доставка и остатки по складам
Регион влияет и на логистику. Адрес доставки хранится в заказе, а доступность товара определяется остатками на конкретном складе. Остатки запрашиваются отчётом GET /report/stock/all с фильтром по store.
Типовой сценарий для мультирегионального магазина:
- определить регион пользователя (город, гео);
- выбрать склад региона и запросить остатки по нему;
- показать региональную цену из нужного
priceType; - создать заказ с корректными
organizationиstore.
Так «одна и та же» карточка товара на сайте корректно показывает наличие и цену для Москвы и для СПб, опираясь на реальные данные склада, а не на усреднённые значения.
Как не размножить конфигурацию
Соблазн под каждый регион завести отдельную интеграцию ведёт к хаосу. Правильнее — единый коннектор с региональной конфигурацией:
- таблица соответствия «регион → организация, склад, тип цены»;
- часовой пояс аккаунта как единый параметр конвертации дат;
- общие правила маппинга номенклатуры, а региональными остаются только цены и остатки;
- единый журнал обмена с меткой региона для диагностики.
На 1С-Битрикс это ложится на инфоблоки и настройки обмена: одна логика, параметризованная регионом, вместо дублей кода на каждый город.
Итог
Региональная настройка интеграции с МойСклад — это грамотное использование организаций, складов, точек продаж и типов цен плюс аккуратная работа с датами по часовому поясу аккаунта. Регион задаёт не только цену и остаток, но и налоговый режим юрлица, а значит и корректность чека.
Мы в B2Bsite проектируем мультирегиональные интеграции как единый параметризованный обмен, без дублей под каждый город, и сопровождаем их с учётом часовых поясов и налоговых режимов. Поможем настроить работу «в Москве и СПб» без рассинхрона.
Частые вопросы
Есть ли в МойСклад отдельная сущность региона?
Нет. Регион моделируется комбинацией организации, склада, точки продаж и типа цены. По ссылкам документа на organization и store всегда однозначно определяется регион.
В каком часовом поясе приходят даты из API?
В часовом поясе аккаунта, в формате yyyy-MM-dd HH:mm:ss без указания зоны. Трактовать эти даты как UTC нельзя — иначе суточные границы отчётов сместятся.
Как хранить разные цены для Москвы и СПб?
Через типы цен: у номенклатуры массив salePrices, где каждый элемент связан со своим priceType. Один товар одновременно несёт региональные цены.
Почему тип цены лучше выбирать по href, а не по названию?
Названия типов цен можно переименовать, а идентификатор href остаётся стабильным. Привязка по названию ломается при первом же переименовании.
Как регион влияет на налоги?
Налоговый режим задаётся на уровне организации. Если в регионах разные юрлица, у них могут отличаться система налогообложения и ставки НДС, что напрямую влияет на чек.
Почему нельзя пробить чек с НДС от юрлица на УСН?
На упрощённой системе НДС в позициях не выделяется. Несогласованность налогового режима организации и ставок НДС приводит к отказу при фискализации.
Как показать остатки по конкретному городу?
Запросить отчёт /report/stock/all с фильтром по нужному складу store. Так карточка товара покажет реальное наличие для региона, а не усреднённое значение.
Нужно ли делать отдельную интеграцию под каждый регион?
Нет, это порождает дубли и хаос. Лучше единый коннектор с региональной конфигурацией: таблица соответствия регион — организация, склад и тип цены.
Поможем с настройкой и поддержкой Для разработчиков
Поможем с настройкой, доработкой и поддержкой Для разработчиков.