Как правильно реализовать "баланс" на торговой площадке?

[iSlayter]

Как правильно реализовать "баланс" на торговой площадке?

Уже довольно давно занимаюсь разработкой торговой площадки (на подобии plati.ru).

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

Система следующая: существуют определённые типы категорий для товара в которых продавцы его размещают.

Особенности:

Тип - рассылка.

Пользователь подписывается на N выпусков выбранного автора.
Доставка рассылки осуществляется посредством email, icq и sms. СМС здесь очередная особенность, т.к. необходимо в стоимость рассылки заказанной пользователем таким образом прибавлять стоимость смс сообщения. Где и как эту наценку хранить правильно мне не совсем ясно. Так же, как, впрочем, и сам платежи.
Причём, надо так же как-то рассчитывать "долги" пользователя. Например, пользователь оплатил 20 выпусков рассылки. Надо дать администратору площадки возможность видеть, что автор такой-то рассылки не сделал ещё N оплаченных выпусков пользователями (умножаем на стоимость и показывает в качестве долга).

Тип - услуга.

Продавец даёт информацию о каких-либо учебных курсах. Определяет цену за одну заявку, определяет количество возможных заявок с данной торговой площадки. Деньги снимаются с WM или ЯД во время добавления товара, разово.

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

Тип - цифровой товар.

Здесь всё просто. Выбрал товар, выбрал способ доставки, оплатил, получил выбранным способом.

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

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

В таблице с рассылками хранить количество пред.оплаченных выпусков и количество полученных (банальный ++ после отправки). В отдельной таблице хранить сами выпуски (вдруг до кого письмо или sms'ка не дойдёт, чтобы можно было легко переотправить). Просмотр архива делать, думаю, не стоит (удобно, спору нет), но по ТЗ пользователи покупают все без регистрации и как-либо отличить пользователей без учётной записи представляется довольно геморройным делом(можно после покупки выдавать уникальные ключи доступа к этой части площадки, после ввода которого пользователь видит все полученные оплаченные им рассылки, необходима так же возможность закрепления данного ключа за текущим IP адресом, дабы не смогли уперев ключик воспользоваться им. Короче -- гемор, связываться не буду).

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

Таблица с товарами каждый ряд - это финансовая операция (конкретнее - получение N'ой суммы от покупателя). Тут всё просто.


Как Вы думаете, имеет ли описанный мной способ право на существование?

Я вижу один очень серьёзный минус - трудности с удалением: надо удалить и товар и файлы к нему относящиеся и операции из таблицы соответствующей типу товара, и дополнительную информацию из вспомогательных таблиц если товар -- это услуга или рассылка

 

[Bu-Bu]

Так все давно сделано в интернет-магазинах, коих сонм - ID товара, ID продавца и покупатель, который каждым своим выбором кладет себе ID+ID, отсюда и весь учет. Так что основных таблицы как минимум три - продавцы, товары, покупатели.

 

[iSlayter]

Bu-Bu, я, безусловно, признателен, что вы прочитали первые несколько предложений топика, но, на площадке понятия "покупатель" нет. Есть простые гости, которые покупают товары без регистрации. Таково требование заказчика.

 

[Bu-Bu]

Без регистрации? А каким образом они оплачивают? Все равно же что-то выписывают типа счета. Вот и "подсмотреть" В чем сложность-то? И потом, если он что-то выбрал, то по-любому это должно фиксироваться при вводе.

 

[iSlayter]

Во-первых, зачем нужна регистрация для оплаты? Ввели данные (ФИО, email, номер телефона, icq - в зависимости от выбранного товара и способа доставки), после чего перешли на мерчант и оплатили.

Во-вторых, если есть желание помочь, вернитесь к этому моменту треда:
"Вопрос: как и где хранить информацию по данным операциям таким образом, чтобы легко было получить текущий баланс продавца?".

Все операции имеют разную структуру. Для разных групп товара пользователи будут заполнять разные поля. Нет смысла делать таблицу с 30ю колонками, имхо, куда проще разбить на группы таблиц и вспомогательные таблицы. Собственно, я интересуюсь правильный ли я способ выбрал. Советы "подсмотреть" или "правильно" или "неправильно" - не катят. Хотелось бы просто узнать, как товарищи форумчане реализовывали бы данную задачу, попадись она им.

 

[Bu-Bu]

Так тут и есть главное в любом магазине - ID товара, ID продавца. СМС - тоже товар с привязкой к ID продавца, если отправляется за его товар. Больше тут и мудрить нечего - какие еще 30 столбцов? Давайте посчитаем - для товара - ID, название, категория, описание, цена, количество (плюс произвольные поля), для продавца - ID, название, реквизиты, описание, платежный баланс (сальдо то бишь), а для покупателей - условное наименование, ID товара+количество и ID продавца. И все.

 

[iSlayter]

СМС - это не товар с привязкой к ID продавца. Наценка на стоимость делается для покупателя. После чего из общей стоимости необходимо вычесть стоимость смски и отнять определённый % комиссии, а далее положить куда надо.

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

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

Если же пользователь оплатил 20 выпусков размещённой рассылки, то вычитать из сальдо 20 * стоимость одного выпуска? В таком случае я могу заработать на площадке 10 тысяч рублей. Пользователи купят у меня рассылок на 15 тысяч рублей. Я в глубоком минусе. Хочу разместить услуги (пользователи заполняют анкету). Общим количеством 50 анкет по 10р за штуку и я должен буду закинуть на площадку не 500р, а 5 500р.

Это идеологически верно?

-~{}~ 10.08.08 20:24:

или же в случае с услугами было бы более верным не смотреть на сальдо продавца а заставлять внести необходимую сумму?

 

[Bu-Bu]

Вам зачем излишняя морока? СМС - такой же товар стоимостью скажем 20 рэ. Если покупатель запросил СМС под товар продавца, то с кого нужно получить эти 20 рэ? С продавца. Просто вести отдельно логи этих СМС, чтобы предоставить отчет по окончании какого-то периода. И остальные телодвижения нужно привязывать не к цене товара, а к стоимости услуг + цена товара. Непонятно: с кого и как Вы хотите получать деньги. Если рассылки - это Ваша личная инициатива, то закладывайтесь на дополнительные комиссии с продавцами

 

[atv]

Хотелось бы просто узнать, как товарищи форумчане реализовывали бы данную задачу, попадись она им.

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

Из прочитанного, хотелось бы отметить:

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

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

Я бы ещё посоветовал добавить понятие заказа, который связан связью многие-ко-многим с разными типами товара. Это позволит вести учёт операций в одном месте.

 

[iSlayter]

Bu-Bu, я бы и рад, но, опять же, это требование заказчика. Продавец задаёт цену товара, в случае дополнительных расходов их оплачивает покупатель. Мне не совсем понятно такое положение вещей, но "в морг, значит в морг".

atv, вот! Трудности заключаются именно с проектированием структуры! Что бы вы рекомендовали хранить в сущности "заказа"? id товара, id типа товара, данные покупателя и внесённая им денежная сумма? В отдельной таблице со связью многие-ко-многим в любом случае придётся хранить выбранные способы доставки покупателем (например: icq, sms или icq, email, sms).

 

[atv]

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

Это уже относиться к бизнес логике, которая будет опираться на структуру данных. Типичная структура данных в таких случаях: продавец, покупатель, товар, заказ и операция передачи денег от покупателя к продавцу. А уже на операцию накладываете бизнес логику по вычетам, надбавкам, доплатам и т.д.

Не путайте структуру данных с бизнес логикой!

 

[Bu-Bu]

Тут проблема, которая будет неразрешимой - смски могут утопить весь проект. Поэтому все можно реализовать, но закладываться под дополнительные расходы или подключать внешние сервисы, такие как оплата через телефон, но там комиссии такие, что Ваши клиенты просто разбегутся. Ищите баланс между ценой товара и накладными расходами, тогда остальное легко сложится в картину.

 

[grigori]

Bu-Bu
вопрос бизнес-плана и комиссионных выходит за рамки данного обсуждения, это не проблема iSlayter

 

[iSlayter]

нужно несколько дней провести в дали от компьютера в обнимку с ТЗ, ручкой и 500 страничной пачкой чистой бумаги формата А4. так будет более продуктивно, пожалуй

 

[Bu-Bu]

Автор оригинала: grigori
Bu-Bu
вопрос бизнес-плана и комиссионных выходит за рамки данного обсуждения, это не проблема iSlayter

Пока он не решит эту проблему о PHP ему думать рано. В PHP я любитель, а в бизнесе не совсем

 

[prolis]

если без велосипедов:
таблица Orders (здесь и далее указаны только необходимые поля):
IdCustomer (идентификатор заказщика)
IdProduct (идентификатор продукта/услуги)
CntProduct (кол-во заказанной услуги-товара*)
DateOrder (дата создания заказа)
DateClose (дата предоставления услуги)

*CntProduct - если НЕ возможно единовременное закрытие сделки, то количество равно 1

Теперь про СМС: кустомер заказывает 20 рассылок и 20 смс
-в таблицу вносится 20 записей с продуктом "рассылка" и 20 записей с продуктом "СМС-уведомление"
по мере оказания услуг закрываются ордера необходимой датой

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

Таблица с предложениями Products:
idProduct
SumItem - сумма за один продукт
CntProduct - количество

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

 

[atv]

Что бы вы рекомендовали хранить в сущности "заказа"? id товара, id типа товара, данные покупателя и внесённая им денежная сумма?

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

Внесённая покупателем сумма - это сущность "операция", о которой я писал выше, или платёж. Из истории платежей можем получить текущий баланс.

В отдельной таблице со связью многие-ко-многим в любом случае придётся хранить выбранные способы доставки покупателем (например: icq, sms или icq, email, sms).

А вот способ доставки, больше относиться к заказу.

 

[iSlayter]

prolis, вы думаете стоит на каждое смс создавать запись?

Может эту информацию лучше хранить в таблице с заказом? В поле `if_sms` в случае если тип доставки выбран SMS там будет храниться количество предоплаченных сообщений, которое будет уменьшаться после каждого выпуска. В поле `self_cost` будет храниться себестоимость SMS сообщения на момент оплаты заказа, а в поле `extra_charge` будет храниться наценка на SMS сообщение, установленное на тот момент времени. Это делается для того, чтобы предоставить управленцам площадки статистику (в виде графика) заработка на SMS (кощунственная затея, конечно, в плане отношения к пользователю, ну да некуда деваться).

Как поле `if_sms` станет равным 0 происходит обновление информации по этому заказу - `active` = 0, после чего выпусков рассылок пользователь более не получает.

atv, если ID товара не хранить в таблице заказа, то как вообще потом находить эту самую нужную строку с конкретным заказом?

 

[prolis]

iSlayterразделить эти две услуги по разным записям лучший выход, это дает вам возможность масштабироваться хоть до пакета "ВИП СМС+емейл+голубиная почта", не меня бизнес-логики
наценку на смс вы и так хорошо посчитаете, только вот систему скидок и наценок нужно вынести в отдельную сущность и привязывать её к продавцам или покупателям или сделкам (например при сумме заказа больше x рублей)
только храните там коэффициенты или фиксированные суммы
Обнулять ничего я не вижу смысла: как происходит рассылка - выбираются все записи с оплаченными заказами данного оповещения, происходит рассылка и оповещение, закрываются оба ордера и в следующую рассылку они уже не попадут, если не останется у клиента незакрытых ордеров.

 

[atv]

вы думаете стоит на каждое смс создавать запись?

Стоит. Тут я согласен с prolis

если ID товара не хранить в таблице заказа, то как вообще потом находить эту самую нужную строку с конкретным заказом?

А в чём проблема?