Перейти к основному содержимому

Commercial Model — Коммерческая модель, цена, settlement и канальные условия

Версия: 1.0
Дата: 23.04.2026
Статус: Готов к обсуждению

Назначение документа​

Этот документ фиксирует commercial model как самостоятельный обязательный домен платформы.

Его задача — жёстко собрать в одном месте:

  • из чего вообще состоит цена в платформе;
  • где проходит граница между supplier price, platform commercial logic, quoted price и settlement-relevant figures;
  • как коммерческие правила зависят от tenant, agency, partner, channel и actor context;
  • что именно платформа обещает в коммерческом смысле на этапах discovery, offer, quote и booking;
  • как должны мыслиться комиссии, markup, fee, override, discount и иные денежные модификаторы;
  • как должна быть устроена settlement-модель между платформой, поставщиком, агентством, партнёром и иными участниками.

Без этого документа pricing, quote, partner model, agency model и booking остаются логически связанными, но концептуально недоформленными.

Опорные документы​

Почему Этот Документ Нужен Отдельно​

В Главные выводы и проблемные зоны платформы уже зафиксировано, что commercial domain пока недооформлен как самостоятельный слой.

Это критично, потому что без отдельной коммерческой модели платформа не сможет последовательно определить:

  • какую цену видит агент;
  • какую цену видит партнёр;
  • какую цену видит B2C-клиент;
  • где заканчивается supplier economics и начинается platform commercial policy;
  • как оформляется quote;
  • что именно потом участвует в booking;
  • какие суммы участвуют в settlement и reporting;
  • как считать overrides, commissions, fees и discounts.

Commercial domain здесь не является “просто калькулятором цены”. Это часть архитектурного ядра платформы.

При этом commercial domain не закрывает собой:

  • partner clearing and credit exposure;
  • tenant enablement policy;
  • post-booking amendment and cancellation execution.

Эти контуры связаны с ним, но требуют собственной доменной фиксации.

Что Master Plan Требует От Этого Документа​

Этот документ напрямую закрывает часть обязательных пунктов из Documentation Master Plan — Project 15 Structure Snapshot:

  • 197 — определить состав цены: source price, markup, fee, commission, discount и финальную стоимость;
  • 198 — зафиксировать правила округления, валютной конвертации и расчёта итоговой цены для разных рынков;
  • 199 — определить, в какой момент цена считается подтверждённой для клиента, агента и внутренней системы;
  • 200 — описать модель коммерческого предложения, срок его жизни и условия пересчёта;
  • 201 — определить правила индивидуальных ценовых условий для партнёров, агентств и каналов продаж;
  • 202 — зафиксировать принципы пересчёта цены при изменении supplier data, валюты или состава услуги;
  • 246 — зафиксировать модель settlement между платформой, поставщиком, агентством и другими участниками цепочки.

Ни один из этих вопросов не должен оставаться размазанным между pricing, booking, partner API и clients.

Главный Принцип Commercial Model​

Платформа должна различать:

  1. supplier economics
  2. normalized commercial basis
  3. channel / tenant / partner / agency-specific commercial policy
  4. quoted commercial promise
  5. settlement-relevant financial reality

Если платформа начинает использовать один и тот же monetary object для всех пяти ролей, она теряет:

  • объяснимость цены;
  • управляемость overrides;
  • честность quote-level обещания;
  • устойчивость booking path;
  • пригодность к settlement и reporting.

Commercial Domain Не Равен Pricing Math​

Цена в платформе — это не только арифметика.

Commercial domain включает:

  • правила формирования final visible price;
  • правила channel-specific visibility;
  • правила quote validity;
  • правила индивидуальных условий;
  • правила downstream settlement;
  • правила пересчёта при drift supplier data;
  • правила коммерческой ответственности между участниками.

Поэтому commercial model должен быть доменным документом, а не набором formulas appendix.

Базовые Денежные Слои​

На текущем этапе разумно закрепить как минимум пять смысловых слоёв.

1. Supplier Raw Price​

Это денежная реальность поставщика, как он её возвращает.

Она может включать или не включать:

  • налоги;
  • fees;
  • service charges;
  • cancellation penalties;
  • occupancy-based additions;
  • currency-specific rounding.

Эта цена важна, но сама по себе почти никогда не должна считаться финальным platform promise.

2. Normalized Base Price​

Это supplier-derived price после приведения к внутренней нормализованной форме.

Она нужна для:

  • сопоставимости;
  • explainability;
  • дальнейшей коммерческой логики;
  • честного перехода к quote.

3. Commercial Rule Output​

Это результат применения platform / tenant / channel / partner / agency-specific правил:

  • markup;
  • commission logic;
  • fee;
  • discount;
  • override;
  • currency policy;
  • rounding policy.

Этот слой уже не является supplier truth. Это platform commercial interpretation.

4. Quoted Price​

Это цена, зафиксированная в Quote для конкретного actor / tenant / workspace / channel context.

Именно quoted price является самым близким к коммерческому обещанию платформы в пределах quote validity window.

5. Settlement-Relevant Figures​

Это денежные величины, нужные для:

  • supplier payable;
  • agency commission accounting;
  • platform revenue accounting;
  • partner revenue share;
  • refund and cancellation calculations;
  • reconciliation and reporting.

Они могут совпадать с quoted price частично, но не обязаны быть тождественными ему.

Состав Цены​

Платформа должна быть способна явно мыслить состав final visible price.

Минимальные Компоненты​

  • source_price
  • source_tax_component, где применимо
  • normalized_base_price
  • platform_markup
  • agency_markup
  • partner_override
  • service_fee
  • discount
  • currency_conversion_adjustment
  • rounding_adjustment
  • final_visible_price

Что Нельзя Делать​

  • смешивать commission и markup как одну абстрактную “надбавку”;
  • терять origin каждого денежного компонента;
  • скрывать, какая часть суммы supplier-derived, а какая platform-derived;
  • использовать один field price без смыслового слоя.

Коммерческие Акторы​

Commercial model должен опираться на модель субъектов из Tenancy And Identity — Субъекты платформы, изоляция и модель доступа.

Internal Platform​

Платформенный контур задаёт:

  • базовые commercial rules;
  • channel policies;
  • settlement logic;
  • override governance;
  • revenue accounting policy.

Agency​

Agency — working and commercial actor, который может иметь:

  • свои price visibility rules;
  • свои markup policies;
  • свои customer-facing proposal rules;
  • свою commission / margin model;
  • свои workspace-bound commercial permissions.

Partner​

Partner — contract actor, который может иметь:

  • отдельные price policies;
  • отдельные contract scopes;
  • отдельные overrides;
  • отдельные revenue-share or fee model;
  • отдельную settlement logic.

Client / End Customer​

Конечный клиент не обязательно является самостоятельным commercial configurator, но именно ему может быть адресовано final visible proposal.

Supplier​

Supplier остаётся внешним economic counterparty, но его economics не должны напрямую подменять внутреннюю коммерческую модель платформы.

Agency И Partner Не Должны Сливаться В Один Commercial Type​

Это один из ключевых выводов.

Agency​

Agency использует платформу для собственной агентской работы и customer servicing.

Для неё важны:

  • working quote model;
  • margin control;
  • customer proposal model;
  • booking follow-up;
  • commission and performance accounting.

Partner​

Partner взаимодействует через внешний contract surface.

Для него важны:

  • contract pricing policy;
  • API-visible commercial semantics;
  • quotas and channel constraints;
  • partner-specific override model;
  • partner settlement logic.

Они могут быть похожи как organizational types, но commercial behavior у них не обязан совпадать.

Канальные Commercial Rules​

Коммерческая политика должна быть channel-aware.

B2B Agency Surface​

Может требовать:

  • richer price breakdown;
  • quote validity transparency;
  • access to agency-specific margin semantics;
  • proposal-oriented commercial view.

Partner API Surface​

Может требовать:

  • contract-safe price representation;
  • stable machine-readable amounts;
  • explicit currency and rounding semantics;
  • channel-specific override handling.

B2C Surface​

Может требовать:

  • simplified visible price;
  • stricter presentation compliance;
  • hiding internal operational and margin internals;
  • different fee disclosure policy.

Internal Operational Surface​

Должен уметь видеть:

  • monetary components;
  • override source;
  • settlement preparation;
  • pricing anomalies;
  • manual commercial exceptions.

Quote Как Коммерческая Фиксация​

Quote должен считаться коммерческой фиксацией, а не просто красивым UI object.

Quote Должен Фиксировать​

  • actor context;
  • tenant / workspace context;
  • applied commercial policy;
  • final visible price;
  • validity window;
  • assumptions and unresolved constraints;
  • revalidation basis;
  • publication readiness для клиента или downstream consumer.

Quote Не Должен Подменяться​

  • cached search result;
  • indicative offer card;
  • preliminary ranking projection;
  • booking confirmation.

Когда Цена Считается Подтверждённой​

Это один из самых важных коммерческих вопросов.

Платформа должна различать:

1. Indicative Price​

Это цена на уровне discovery / offer preview.

Она:

  • может быть показана;
  • может быть полезной для выбора;
  • не обязана быть окончательной;
  • должна сопровождаться freshness and revalidation semantics.

2. Quoted Price​

Это коммерчески зафиксированная цена в рамках Quote.

Она:

  • имеет validity window;
  • относится к конкретному actor/context;
  • является честным коммерческим обещанием в пределах условий quote;
  • всё ещё может требовать explicit booking-time validation по установленным правилам.

3. Booking-Time Confirmed Price​

Это цена, прошедшая тот уровень подтверждения, который платформа считает достаточным для перехода к transactional commitment.

4. Settlement-Relevant Confirmed Figures​

Это уже сумма и структура сумм, пригодные для:

  • supplier settlement;
  • partner settlement;
  • agency commission accounting;
  • reporting;
  • refund math.

Quote Lifetime И Repricing​

Commercial model должен жёстко закрепить, что quote не является вечным.

Quote Lifetime Должен Зависеть От​

  • supplier freshness model;
  • volatility of price and availability;
  • channel type;
  • product type;
  • commercial rule sensitivity;
  • composition complexity в Tour Builder.

Repricing Должен Быть Отдельным Сценарием​

Платформа должна различать:

  • full re-quote;
  • partial repricing;
  • revalidation without price change;
  • supplier drift with unchanged visible price;
  • supplier drift requiring quote invalidation.

Currency Policy​

Commercial model должен фиксировать currency discipline.

Нужно Различать​

  • supplier/source currency;
  • normalized internal currency basis, если нужен;
  • quoted display currency;
  • booking payment currency;
  • settlement currency;
  • exchange-rate reference and timestamp.

Нельзя Допускать​

  • неясности, какая именно сумма была конвертирована;
  • ситуации, где visible price и settlement figures основаны на разных незафиксированных exchange inputs;
  • silent conversion rules, которые невозможно объяснить.

Rounding Policy​

Округление должно быть частью commercial model, а не случайным UI formatting detail.

Нужно Зафиксировать​

  • где округление применяется;
  • к каким компонентам оно применяется;
  • допускается ли channel-specific rounding;
  • как rounding влияет на visible price;
  • как rounding differences отражаются в settlement figures.

Override Policy​

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

Override Может Быть​

  • platform-wide;
  • tenant-specific;
  • agency-specific;
  • partner-specific;
  • channel-specific;
  • case-specific manual override.

Для Любого Override Нужно Понимать​

  • кто его создал;
  • на какой scope он действует;
  • сколько живёт;
  • влияет ли он на quote, booking или только presentation;
  • допустим ли он для partner/B2C surfaces;
  • должен ли он проходить governance or approval path.

Discount And Fee Policy​

Discount и fee не должны растворяться в одном общем “price adjustment”.

Discount​

Может быть:

  • promotional;
  • channel-specific;
  • customer-specific;
  • agency-specific;
  • partner-funded;
  • platform-funded.

Fee​

Может быть:

  • service fee;
  • payment-related fee;
  • fulfillment fee;
  • partner channel fee;
  • support/exception fee, если платформа такое допускает.

Платформа должна быть способна объяснить происхождение каждого такого компонента.

Settlement Model​

Settlement — это не приложение к booking. Это часть commercial core.

Платформа Должна Допускать Как Минимум Следующие Settlement Relations​

  • platform -> supplier
  • platform -> agency
  • platform -> partner
  • agency -> platform, если бизнес-модель этого требует
  • client payment -> platform or merchant-of-record counterparty, в зависимости от business model

Settlement Model Должен Отвечать На Вопросы​

  • кто является economic counterparty;
  • кто является merchant of record, если это релевантно;
  • какая сумма payable supplier;
  • какая сумма является platform revenue;
  • какая сумма является agency commission or margin;
  • какая сумма относится к partner revenue-share or fee;
  • как это меняется при cancellation, amendment, refund, partial failure.

Refund, Cancellation And Amendment Economics​

Commercial model должен охватывать не только happy path.

Нужно Зафиксировать​

  • какие денежные компоненты возвратные, а какие невозвратные;
  • как supplier penalty влияет на downstream visible economics;
  • как перерасчитывается agency / partner share;
  • как обрабатываются rounding and conversion differences at refund time;
  • какие суммы считаются preliminary, а какие final after reconciliation.

Commercial Governance​

Коммерческий слой тоже требует governance.

Governance-Сценарии Могут Включать​

  • suspicious pricing anomaly review;
  • override approval;
  • blocked publication of commercially inconsistent offer;
  • settlement discrepancy review;
  • partner/agency pricing dispute handling;
  • manual repricing decision;
  • audit of channel-specific visibility rules.

Commercial Model И Storage / Persistence​

Commercial model должен иметь устойчивое отражение в persistent model.

Должны Храниться​

  • commercial policy sets;
  • channel/tenant/partner pricing rules;
  • quote-time commercial snapshot;
  • booking-time commercial snapshot;
  • settlement-relevant events;
  • override audit trail;
  • currency and conversion references;
  • fee / discount / commission components where they matter for audit.

Что Нельзя Оставлять Только В Runtime​

  • applied commercial rule set for a quote;
  • origin of final visible price;
  • settlement-relevant calculation basis;
  • partner or agency override reason;
  • refund calculation trace.

Commercial Model И API / Clients​

Commercial model напрямую влияет на API Contracts — Surface Contracts и правила внешнего взаимодействия и Clients Layer — Клиентские поверхности и рабочие модели.

Это Означает​

  • contracts должны честно показывать price view;
  • quote endpoints должны фиксировать commercial context;
  • booking contracts не должны скрывать repricing or revalidation requirements;
  • agency workspace может видеть richer commercial breakdown than B2C surface;
  • partner API должен получать contract-safe, stable monetary semantics;
  • client-facing published proposal не должен притворяться внутренним расчётным документом.

Commercial Model И Supplier Layer​

Commercial model не должен подменять supplier economics, но обязан уметь работать поверх него.

Это Означает​

  • supplier raw price не равен platform visible price;
  • supplier tax logic не обязана совпадать с final displayed breakdown;
  • supplier drift может требовать re-quote;
  • слабая supplier transparency может снижать commercial certainty;
  • supplier limitation может менять quote lifetime and booking-time confirmation rules.

Следующий Практический Вывод Для Архитектуры​

После фиксации этого документа платформа должна считать commercial model самостоятельным опорным контуром рядом с:

  • domain model;
  • tenancy and identity;
  • offer/pricing/booking semantics;
  • tour builder;
  • data governance and matching.

Иначе коммерческая логика снова начнёт расползаться по pricing, booking, partner API и клиентским поверхностям.

Что Должно Быть Перепроверено После Этого Документа​

Уточнение под Фазы 4–6 (28.04.2026) — связь с payment, settlement, SLA credits, isolation​

Документ опубликован 23.04.2026 (Фаза 3) как фундамент коммерческой модели. После Фаз 4–6 ряд понятий получил каноничные источники истины; эта секция фиксирует обязательные связи.

Связь с платёжным доменом​

reference/payment-domain.md (Фаза 4) — каноничный источник для PaymentIntent / Refund / Chargeback / Settlement lifecycle. Этот документ описывает commercial semantics (quoted promise, repricing, settlement-relevant figures); payment-domain — operational lifecycle платежей. Связь:

  • Quote → PaymentIntent при booking commit;
  • Refund (commercial decision) → выполняется через payment-domain operations;
  • Chargeback (downstream financial reality) → каноничный workflow в payment-domain.

Связь с booking state machine​

reference/booking-state-machine.md (Фаза 5) — 14 каноничных состояний с каноничными именами. Этот документ упоминает booking lifecycle на высоком уровне; каноничные имена состояний — в booking-state-machine. Особо важно:

  • unknown_external_state (8-е состояние) — особый случай для commercial fixation: settlement freeze до manual review;
  • разделение supplier_confirmed vs platform_confirmed — commercial promise держится только при platform_confirmed.

Связь с saga Tour Builder​

reference/tour-builder-operational-model.md (Фаза 5) — multi-component tours имеют per-component commercial logic + tour-level pricing (per-tour markup, package discount). Saga координирует commercial outcome при partial failure (compensation operations).

Связь с SLA service credits как revenue correction​

operations/sla-and-on-call-model.md (Фаза 6) — service credits при SLA breach (5%/10%/25%/50%) — это negative revenue adjustment в settlement периоде. Commercial model должна учитывать credits как отдельный класс financial events.

Связь с tier-моделью API as Product​

reference/api-as-product.md (Фаза 4) — 4 tier (Free / Starter / Professional / Enterprise) определяют:

  • какие commercial flows доступны (например, Tour Builder commercial — Professional+);
  • какие commercial policies применяются (subscription + usage / revenue-share / hybrid);
  • какой uplift на dynamic pricing.

Связь с уровнями тенантной изоляции​

reference/multi-tenant-isolation-strength.md (Фаза 5) — 3 уровня изоляции напрямую связаны с commercial:

  • dedicated_infrastructure → dedicated_infrastructure_fee revenue stream (см. economic-model);
  • per-tenant commercial policies могут различаться по isolation tier.

Связь с EU TOMS VAT и Package Travel Directive​

reference/compliance-and-legal.md (Фаза 4) — commercial figures для EU customer'ов:

  • EU TOMS — VAT на маржу платформы (revenue minus supplier cost);
  • Package Travel Directive — для Tour Builder products требует insolvency protection как commercial obligation;
  • merchant-of-record модель влияет на commercial responsibility chain.

Связь с Economic Model​

reference/economic-model.md (Фаза 4) — финальный синтезирующий слой экономики платформы. Этот документ описывает commercial semantics конкретного flow; economic-model — системную картину revenue streams и unit-economics.

Каноничный итог уточнения​

Этот документ остаётся базовым каркасом коммерческой модели (quoted promise, repricing, settlement-relevant figures, channel-aware policies). Реализация и расширения:

Уточнение выполнено через no-destruction.