Схемы продаж и ценообразование

[langovoi]

Для учета билетов на своей стороне нам нужны схемы продаж и функционал по формированию цены.

Цена - это структура, описывающая формирование цены в зависимости от каких-то условий.
Состоит из стартовой цены (price) и модификаторов (modifiers).
Каждый модификатор описывает новую цену (price) и набор ИЛИ условий для ее активации (conditions).
Условия могут быть двух типов: по количеству проданных билетов (sales_count) и по датам (active_from, active_to).
Каждое условие должно быть уникально для одной цены. То есть не может быть два условия sales_count=50 или пересечения дат в рамках цены, даже в разных модификаторах.

Схема продаж - это структура описывающая категории билетов.
Схема имеет название (title) и связь с упорядоченными категориями (order, title и опциональный description).

API для этой задачи не нужно.

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

[TyVik]

Как насчёт добавить сущность Modifier, в которой будут 4 поля: active_from, active_to, sales_count и price. price я хочу сделать абсолютной, чтобы сразу исключить множество ошибок.

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

А как это будет с QTicket стыковаться? Цену-то мы, допустим, определили, а что в запросе на оплату должно улететь?

[langovoi]

Как насчёт добавить сущность Modifier, в которой будут 4 поля: active_from, active_to, sales_count и price. price я хочу сделать абсолютной, чтобы сразу исключить множество ошибок.

Мне не критично, хотел лишь упростить формат, всем равно прийдется схлопотать в conditions.

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

Не модификаторы, а цена. И сейчас это делать не нужно.

А как это будет с QTicket стыковаться? Цену-то мы, допустим, определили, а что в запросе на оплату должно улететь?

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

[TyVik]

Насчёт первого и последнего пунктов понял. По второму не понятно что именно не нужно делать. В моём понимании:

• у Event есть список типов билетов
• у типа билета есть список модификаторов.

[langovoi]

Сейчас расчёт цены не нужно никакой делать. Только реализовать модели данных и дать возможность их заполнять.

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

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