Dimitry Sibiryakov, интересует ответ на вопрос с точки зрения технической реализации в первую очередь. :)

В дополнение - в данном случае суммы совершенно не сопоставимы... ) С суммами транзакций вышеназванного господина) Речь о выкупе товаров с онлайн-магазинов вроде ебей и т.п., тут большим цифрам браться неоткуда..

Кот Матроскинatrsameuser,
Я думаю, проблема из-за того, что курс не должен быть атрибутом сущности "сделка" - Ваш пример это адекватно показывает.
Т.е. есть операция "конвертация" - у нее есть курс, и есть операция "сделка" - она происходит уже в целевой валюте, и курса у нее нет.
В таком случае теряется определенная точность.. Хотелось бы, конечно, контролировать данные полностью.
Мысль вчера пришла. Возможно, не самая лучшая.. Возможно я что-то упустил. Но все же хотел обсудить..

Если.. Создать таблицу принадлежности транзакций примерно такой структуры:





При осуществлении фактической оплаты товаров оператором напротив каждой оплачиваемой товарной позиции расположить выпадающий список с возможностью множественного селекта..
Состав списка - транзакции данного конкретного клиента..





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

авторЕдинственное, что у меня большие сомнения в том что вы реально меняете клиентские рубли на валюту до оплаты за товар.
К счастью или к сожалению, именно так и выстроен бизнес-процесс. Переделывание не представляется возможным (пока что).

авторМеняются рубли на валюту сразу при зачислении??
Не сразу, процесс требует время. За которое, кстати, иногда курс меняется. Это другая головная боль..

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

авторЭтот изобретенный велосипед называется партионный учет себестоимости, класически бывает по методу FIFO или LIFO
и совершенно не нужен вам!!!!
Очень бы не хотелось отказываться от полной детализации, так скажем.
Про партионный учет почитал немного, спасибо. Знал бы раньше - не потратил 2 дня на размышления. Изобретение велосипедов отнимает время.. Потому, наверное, и решил на форум зайти ))

Бывает, что заказ клиента может состоять всего из одной позиции (одной строки в личном кабинете). Например, какая-то дорогая вещь или же наоборот, множество мелких и дешевых (1 action-камера или 20 пар перчаток).

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

> Верно тебе ответили. Курс - свойство конвертации. У покупки курса нет!!

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

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

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

Ничего более полезного я придумать не смог по вопросам, разбиравшимся выше. Возьму предложенные способы в работу :)

Далее приходится задумываться о хранении записей движения средств (транзакций).
Предполагается наличие в системе нескольких внутренних счетов (напр., рублёвый_банк1, рублевый_киви, рублевый_вебмани, долларовый и т.п.)




И tran_from_account, и tran_to_account могут быть null.

Если NULL'ом является сущность tran_from_account, то предполагается, что средства поступили извне (ENUM № 1 - пополнение баланса клиентом), а если tran_to_account является типом NULL - то подразумевается вывод средств из системы (ENUM № 3 - возврат денег клиенту, например).

Если же и tran_from_account и tran_to_account не являются NULL'ом - то это будет обмен валюты или перевод со счета на счет (ENUM - тип № 2)

При таком раскладе в базе отсутствуют сущности, отвечающие за определение направления входа и выхода средств (точнее, поступления и вывода). Вместо них используется NULL, т.к. зачисление может осуществляться разными способами, как и вывод может быть произведен на разные кошельки или счета в разных банках.
Была мысль вместо NULL использовать ноль, но тогда бы пришлось создать системный счёт account_id=0, который выступал бы как свалка для описанных выше задач. От этой мысли я отказался.

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

SELECT ( SUM(tran_amount) in transaction_table WHERE tran_owner=150 AND tran_type=1 AND tran_from_account IS NULL ) -
// выше вычислили сумму всех поступлений
......SELECT ( SUM(tran_amount) in tran_table WHERE tran_owner=150 AND tran_type=2 AND tran_from_account IS NOT NULL AND tran_to_account IS NOT NULL ) -
......// вычитаем сумму всех списаний по обмену валюты
............SELECT ( SUM(tran_amount) in tran_table WHERE tran_owner=150 AND tran_type=3 AND tran_to_account IS NULL )
............// вычитаем сумму всех выплат клиенту (возвратов средств)
Возможно, конечно, удастся ограничиться в запросах выше лишь указанием типа транзакций (tran_type) без последующей логической проверки (напр., AND tran_from_account IS NOT NULL AND tran_to_account IS NOT NULL ). Я пока еще не могу точно определить, потребуются ли эти условия для обеспечения целостности расчетов, исключая возможность ошибки где-то.. Или же послужат лишней нагрузкой. Вероятно, ответ придет позднее (в процессе дальнейшей разработки и проектировки).
Готов к критике. :)

Будем считать, что возражений не поступило. И на том спасибо! :)

авторУ тебя на три типа операции - три селекта. А когда типов будет 100 ???
Баланс должен собиратьс простой суммой всех! операций по нему.
Операции себе заведи с + приход, с - уход.
То есть сумируешь ВСЕ по счету, а там уже автоматом приходы прибавляются, уходы отнимаются.
Спасибо за ваш отзыв. Думаю, едва ли этих типов наберется более 5-6...
И т.к. биллинг бивалютный, одним селектом все равно, видимо, не отделаешься..

Забыл добавить - валютный баланс тоже предполагается подсчитывать именно как сумму поступлений на валютный счет от клиента ID=XXX, за вычетом всех списаний и за вычетом всех товаров. Ибо сумма за каждый конкретный товар собирается из множества мелких расходов вроде страховки, цен на доставку по регионам, разных комиссий и прочая-прочая, что невозможно собрать в единый тарифный план или еще как-то структурировать (да и не нужно оно, т.к. значения всех этих страховок, доставок и пр. регулярно меняются на лету).