FSP Capacity 2.0

Оператор описывает здесь три вещи: коммерческие рамки (кого и что он вообще берёт), свободную мощность на сегодня и направления отгрузки.

Оператор и склад, категории и схемы работы описаны в core.

Реестры

Реестр	Что внутри
capacity_model	Сущности listing, storage_capacity, throughput_capacity, routes, route_schedules
storage_types	Закрытый справочник типов хранения и допустимых температурных режимов
rules	CAP-*, ROUTE-*

Витрина склада: listing

Коммерческие рамки, без которых подбор бессмыслен: какие категории и маркетплейсы обслуживаются, какие схемы работы и типы контрагентов, минимальный чек и минимальный объём захода, с какой даты готовы принять, минимальный срок договора, что не берут вообще (restrictions). Ссылка rate_card_id ведёт в прайс оператора в FSP Pricing.

Без этих полей в выдачу попадают операторы, которые такого клиента не возьмут.

Свободная мощность

storage_capacity — свободная мощность по типу и режиму хранения. Тип и режим обязательны: 100 м² заморозки и 100 м² амбиента не одно и то же (CAP-003).

Величина объявляется та, которой оператор реально оперирует (CAP-001). Их три, они равноправны, заполнить нужно хотя бы одну:

Величина	Когда её знают точно
free_m3	Стеллажное и полочное хранение; сравнима с объёмом запроса напрямую
free_pallet_places	Паллетный склад: оператор считает именно места, а не метры
free_m2	Напольное и насыпное хранение

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

Площадь без высоты ёмкость не задаёт (CAP-006). Сто квадратных метров напольного хранения и сто квадратных метров стеллажей в шесть ярусов различаются кратно. Поэтому при заполненной только площади обязательна usable_height_m; без неё ёмкость считается невыводимой, и оператор попадает в выдачу с кодом capacity_not_comparable, а не с придуманным объёмом.

throughput_capacity — свободная пропускная способность: приёмок, отгрузок или обработок в день. Место без пропускной способности бесполезно, поэтому подбор идёт по обоим числам.

Данные декларативны. Стандарт не требует их верификации и не описывает мониторинг занятости: оператор заполняет то, что считает верным, и отвечает за это сам (CAP-002). Единственный механизм — updated_at: сторона, читающая мощность, видит, когда её обновляли, и вправе понизить такого оператора в выдаче или вернуть код capacity_data_stale.

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

Направления: routes и route_schedules

Город склада не отвечает на вопрос «возит ли он на Коледино по четвергам». Направление описывается маршрутом: склад-отправитель, точка назначения, маркетплейс, чьим транспортом идёт отправка.

Точка назначения задаётся кодом из реестра «Пункты назначения», а не строкой: иначе «Коледино» одного оператора и «Каледино» другого — два несравнимых прайса (CAP-005). Для пунктов выдачи и постаматов, которых в реестре нет, есть поле с идентификатором маркетплейса. График лежит отдельными окнами: день недели, время окончания приёма заявок, плановое время отправления.

График определяет доступность отправки и не является ценовым условием, если прайс явно не связывает цену с днём недели (ROUTE-001, CAP-004). При этом route_id может использоваться как поле условия цены в FSP Pricing — направление влияет на ставку, но живёт здесь.

{
  "module": "capacity",
  "title": "FSP Capacity",
  "version": "2.0",
  "versions": [
    "1.0",
    "1.1",
    "2.0"
  ],
  "status": "stable",
  "summary": "Что оператор готов взять, сколько у него свободно и куда он возит. Волатильные данные с отметкой актуальности.",
  "depends": [
    "core"
  ],
  "registries": [
    "capacity_model",
    "storage_types",
    "rules"
  ],
  "rule_prefixes": [
    "CAP",
    "ROUTE"
  ],
  "schema": "schema.json"
}