Что почитать про биллинг?

whirlwind

TDD infected, paranoid
Даже работая с decimal, никто не застрахован от сюрпризов с округлением. Все зависит от того, как считать. При рассчете группы значений, каждое из который является некой долей от базы рассчета, последнее из этих значений нужно рассчитывать не произведением, а разностью между базой рассчета и суммой предыдущих значений. Какая бы база не была, автоматом она до этого не догадается.
 

baev

‹°°¬•
Команда форума
При рассчете группы значений, каждое из который является некой долей от базы рассчета, последнее из этих значений нужно рассчитывать не произведением, а разностью между базой рассчета и суммой предыдущих значений. Какая бы база не была, автоматом она до этого не догадается.
— во-первых, «раСЧёт».
Во-вторых, пример покажите. А то я такой ситуации в нормальном биллинге не могу себе представить.
 

fixxxer

К.О.
Партнер клуба
whirlwind
Все так, ага. В базе это просто удобнее делать. Постгресовский insert|update .. returning field кстати ОЧЕНЬ удобным оказывается.

Про базу я не имел в виду "засунуть все в хранимки", вовсе нет. Это на усмотрение.

Просто куда удобнее в php таскать все строками, а вычислять базой.
 

fixxxer

К.О.
Партнер клуба
baev

Ну скажем партнерка с revenue share и реферальными %. Ну это простейший вариант

Кажется, whirlwind (вроде он) в каком-то треде в "работе" выкладывал схемку, как это выглядит в реальных системах
 

Absinthe

жожо
grigori подскажи пожалуйста софт для работы с PostgreSQL. Я в текущем проекте "наелся". Хочется вменяемого GUI-клиента с вменяемым редактированием скриптов и функций, отладкой, инструментами миграции и анализа, построением IDEF1x диаграмм.
Из софта нашел лишь продукт от Navicat, но часть его функционала нерабочая, а интерфейс делали программисты :)
 

whirlwind

TDD infected, paranoid
— во-первых, «раСЧёт».
Во-вторых, пример покажите. А то я такой ситуации в нормальном биллинге не могу себе представить.
Код:
> create table bill3 (total decimal(10,2), ref decimal(10,2), hold decimal(10,2), remains decimal(10,2));
mysql> insert into bill3 values (99.99, 99.99*0.1, 99.99*0.5, 99.99*0.4);
Query OK, 1 row affected, 3 warnings (0.00 sec)

mysql> select * from bill3;
+-------+-------+-------+---------+
| total | ref   | hold  | remains |
+-------+-------+-------+---------+
| 99.99 | 10.00 | 50.00 |   40.00 |
+-------+-------+-------+---------+
1 row in set (0.02 sec)
 

whirlwind

TDD infected, paranoid
ЗЫ. Все дело в том, что на самом деле нет такого типа данных decimal. Есть вещественное. А decimal подразумевает только два варианта развития событий: нормальное математическое округление (floating point), что при любых вариантах даст те цифры что я в примере привел, либо тупо отбрасывание ненужных разрядов (fixed point), что в итоге даст 9.99 + 49.99 + 39.99 = 99.97. Что так, что так имеем неточность в копейках. Решается это так
Код:
mysql>  insert into bill3 values (99.99, 99.99*0.1, 99.99*0.5, total-ref-hold);
Query OK, 1 row affected, 2 warnings (0.00 sec)

mysql> select * from bill3;
+-------+-------+-------+---------+
| total | ref   | hold  | remains |
+-------+-------+-------+---------+
| 99.99 | 10.00 | 50.00 |   39.99 |
+-------+-------+-------+---------+
1 row in set (0.00 sec)
Это то, о чем я говорил
 

fixxxer

К.О.
Партнер клуба
Ну ясен пень что надо вычитать. А касаемо отбрасывания - все будет нормально, если делать decimal с запасом (X,4)
 

~WR~

Новичок
grigori подскажи пожалуйста софт для работы с PostgreSQL.
EMS PosgreSQL Manager
Минус в том, что он платный, и кряков нет.
Плюс в том, что мне его оплатили. :)

Умеет делать все вышеперечисленное. И диаграммы строит, и EXPLAIN красивый и удобный.
Вообще не представляю работы без него.
 

whirlwind

TDD infected, paranoid
fixxxer с чего будет то? ну в этом конкретном примере будет нормально, а в другом, где более длинная цепочка вычислений, не будет. Проблема в том, что либо мы теряем при вычислениях на отбрасывании остатка, если система рассматривает числа как fixed point, либо получаем перебор, в случае (типовом) когда система оперирует floating point. Когда пора отбрасывать, а когда нет, может знать только программист. В 1C 4 разряда используется, там это не решает проблему, а дает более высокую точность при рассчете всяких налогов что бы не переплачивать копейку с каждой операции :)
 

~WR~

Новичок
Кстати, в postgresql есть такая волшебная вещь, как типа numeric без размерности.
По идее, он полностью соответствует человеческой математике. Без внезапных округлений и потерь разрядов.
 

Semen

Семён
а в чём проблема использовать целые числа, т.е. в копейках, центах ...?
 

~WR~

Новичок
Это кажется хорошей идеей ровно до тех пор, пока вам не понадобится начислить 0.18 налога на сумму 123.45.
И когда таких товаров не один, а сто тысяч, и общая сумма должна сойтись копейка в копейку.

Копейки дробятся, мать их...
 

Dovg

Продвинутый новичок
Мы на уровне проектирования БД договорились с бизнесом, что храним 6 знаков после запятой. При том, что в интерфейсе выводятся только два. Пока проблем не было.
 

Absinthe

жожо
Гуй от лукавого ИМХО.
Не, я понимаю, что крутые перцы используют чисто консоль и emacs вместо IDE, но я привык к удобной работе и без IDE(к примеру) не представляю разработки.
Простой пример - прошелся по своему коду, написанному в редакторе, анализатором PhpStorm. Вывод: основной источник ошибок - человеческий фактор. А IDE его в определенных ситуациях убирает.
 

varan

Б̈́̈̽ͮͣ̈Л̩̲̮̻̤̹͓ДͦЖ̯̙̭̥̑͆А͇̠̱͓͇̾ͨД͙͈̰̳͈͛ͅ
Мы на уровне проектирования БД договорились с бизнесом, что храним 6 знаков после запятой. При том, что в интерфейсе выводятся только два. Пока проблем не было.
я правильно понимаю, что правила округления никак не регламентируются законами?
 

Dovg

Продвинутый новичок
я правильно понимаю, что правила округления никак не регламентируются законами?
При выводе округляем в меньшую сторону. А для внутренних расчетов нам хватает шести знаков после запятой.
 

iceman

говнокодер
varan
если использовать оракл - можно прикрутить oracle workflow.

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

это все фигня, самое главное отчеты.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
т 9.99 + 49.99 + 39.99 = 99.97. Что так, что так имеем неточность в копейках. Решается это так
все будет нормально, если делать decimal с запасом (X,4)
Господа, напоминаю, мы говорим о биллинге, а не об учете посетителей вашего сайта.
Учет финансовых операций делается с размерностью не менее 5, т.е. нормальная размерность поля decimal - 10,5.
Для банковских систем правила хранения и округления прописаны на уровне номативных актов нацбанка.

Округлять до 2х знаков надо только при выводе, причем округлять вниз, иначе клиент, у которого на счету 99,998 увидит у тебя 100,00, но использовать все 100 не сможет, и разозлится.

Кстати, правило "прибавлять 0,00001" хоть и некорректно, но помогает.
 
Сверху