01
Одна программа описывает договор и правила записи
Партнёрская программа в ProGym подходит для фитнес-агрегатора, страхового продукта, ДМС, работодателя или локального корпоративного клуба. В карточке задаются партнёр, номер договора, период действия, часовой пояс, окно записи, срок бесплатной отмены, разрешение листа ожидания и правила поздней отмены. Статусы draft, active, paused, ended и archived позволяют остановить новые операции без удаления истории.
Клуб выбирает модель расчёта: за запись, за фактическое посещение или фиксированную сумму. Ставка и валюта фиксируются в каждой операции, поэтому последующее изменение договора не переписывает прошлый период. Руководитель видит активные программы, количество участников, сегодняшние партнёрские записи и сумму, которая ждёт сверки.
- агрегаторы, ДМС и корпоративные сети;
- период договора и жизненный цикл программы;
- окно записи и дедлайн отмены;
- модель расчёта и ставка;
- контролируемый лист ожидания.
02
Квота защищает общее расписание от oversell
Для программы задаётся дневная квота, лимит мест на отдельное занятие и персональный дневной лимит участника. При записи Core одновременно проверяет статус программы, период допуска, доступность участника, окно бронирования, общую вместимость занятия и партнёрские ограничения. Проверка и создание проходят под блокировкой, поэтому две параллельные заявки не забирают одно последнее место.
Прямые клиенты клуба и партнёрские участники используют одно занятие и одну фактическую capacity. Партнёрская квота ограничивает канал, но не создаёт вторую виртуальную группу. Если мест нет, программа может разрешить waitlist. При отмене квота освобождается, а promotion очереди повторно проверяет правила конкретного партнёра перед подтверждением кандидата.
Повтор внешнего запроса использует idempotency key и возвращает существующую бронь. Изменённые параметры с тем же ключом получают conflict. Это позволяет адаптеру безопасно повторять webhook после таймаута и не создавать дубли в расписании клуба.
03
Участник связан с клиентом клуба
Партнёрский участник создаётся поверх существующей карточки Service Customer. Связь хранит программу, внутреннего клиента, внешний member ID, период действия и статус. Сотруднику не приходится заводить отдельную обезличенную базу, которая расходится с CRM, посещениями и допусками. При этом внешний идентификатор остаётся атрибутом договора и не заменяет глобальную identity клиента.
Перед записью система проверяет active-статус участника и даты допуска. Пауза или отзыв доступа останавливают новые бронирования, а состоявшиеся операции остаются в истории. Сотрудник видит имя клиента, внешний ID и последние записи. Права `service_ops.partners.view`, `manage` и `reconcile` разделяют обычный просмотр, управление договором и финансовое закрытие.
- связь с единой CRM-карточкой;
- внешний ID внутри конкретной программы;
- период и статус допуска;
- история записей и посещений;
- раздельные права сотрудников.
04
Сверка собирается из фактических операций
Reconciliation группирует партнёрские записи по статусу и валюте. В расчёт попадает снимок модели и суммы, сохранённый в момент операции. Для модели per attendance основанием служит подтверждённое посещение, для per booking учитывается запись согласно политике отмены, для fixed сумма закрывается по условиям договора. Бухгалтер видит количество операций и итог до подготовки счёта.
Расчётный период создаётся по выбранной программе и диапазону дат. Черновик можно проверить, затем перевести в finalized, зарегистрировать номер счёта, отметить invoiced и paid. Отмена периода сохраняется отдельным статусом. Сумма, число операций и ссылки на исходные записи позволяют разобрать расхождение с партнёром без ручной склейки таблиц.
Каждый переход проверяет допустимый lifecycle и версию строки. Идемпотентный повтор возвращает тот же результат, а параллельное изменение не затирает работу другого бухгалтера. Все таблицы ограничены организацией через composite foreign keys, RLS и FORCE RLS.
05
Как принять партнёрский контур на пилоте
Создайте тестовую программу с дневной квотой два места и квотой одно место на занятие. Подключите двух клиентов, откройте два занятия в один день и отправьте параллельные записи. Ожидаемый результат: одна запись проходит в выбранный session, вторая получает понятный quota conflict или waitlist согласно правилу. Отмена должна освободить место и позволить следующей операции пройти.
После занятий отметьте одного клиента присутствующим, второго отсутствующим и откройте сверку. Проверьте количество операций и сумму для выбранной модели. Создайте расчётный период, зафиксируйте его, добавьте номер счёта и отметьте оплату. Затем сравните каждую строку с исходной бронью и audit history.
Для интеграции с реальным агрегатором отдельно проверяются подпись webhook, внешний booking ID, повтор после таймаута, недоступность адаптера и восстановление очереди. Provider-specific токены и форматы остаются в адаптере, а договор, квота, участник, занятие и расчёт используют общий Taska Core contract.
- гонка за последнюю квоту;
- direct и partner capacity в одном занятии;
- отмена и освобождение места;
- attendance и расчётная модель;
- период, счёт и подтверждение оплаты.