Как хранить деньги? :-))

← →
DSKalugin © (2005-01-27 13:39) [0]

Какой типа данных вы используете для хранения цен в FireBird/InerBase и почему?
Я использую NUMERIC(15,5)
так же есть еще
-DECIMAL (совсем не ясно чем он отличается от NUMERIC)
-FLOAT типа нашего Single
-DOUBLE PRECISION подозреваю родство с делфийским Double

P.S. 5 знаков после запятой я указываю для повышения точности при вычислении цен. Т.к. приходится умножать на разные коэффициенты типа валютные, скидки, наценки,НДСы... при которых выплывает существенная погрешность если использовать 2 знака после запятой

← →
sniknik © (2005-01-27 14:31) [1]

__Money ?

← →
DSKalugin © (2005-01-27 14:43) [2]

sniknik ©
так точно, количество этих самых Моней :-))

← →
Johnmen © (2005-01-27 14:48) [3]

>DSKalugin © (27.01.05 13:39)

Строго говоря, в ИБ/ФБ есть лишь типы (численные)
INT, INT64(в поздних версиях), FLOAT и DOUBLE PRECISION.
А такие типы, как NUMERIC и DECIMAL, являются псевдотипами и не имеют физической реализации. Они сводятся к указанным выше.
Про всё это написано в прилагаемой документации к конкретной версии сервера.

← →
msguns © (2005-01-27 14:56) [4]

Рекомендую так:
Завести 3 домена:
- "Нормальные" деньги (два знака в дроби)
- Цена (флоат)
- Сумма (4 знака дроби)
- Кол-во (флоат)

Первый идет на рекизиты документов (заголовки накладных, платежи и т.д.)
Второй идет на фактуру накладных. При учете по поставкам и отсутствии фичи авторазноски скидок можно даже заменить флоат на 4-5 знаков дроби (нехай сервак округляет)
Третий для сумм по строке фактуры
Четвертый ясно для чего.

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

← →
Danilka © (2005-01-27 15:14) [5]

NUMERIC(15,2)
шоб бухши не возмущались: "почему в распечатанной счет-фактуре сумма НДС за все товары не совпадает с этой-же суммой посчитаной на куркуляторе???".
:))

← →
DSKalugin © (2005-01-27 15:16) [6]

2 msguns ©

я тоже прихожу к выводу что надо завести отдельный домен
Округляю явсегда на клиенте либо маской поля
TNumericField.DisplayFormat="0.00"
либо функцией
FloatToStrF(Price,fffixed,7,2)

2 Johnmen ©
из этого выходит лучше DOUBLE PRECISION?

<Offtopic>По мнению экспертов, многие россияне продолжают свои сбережения хоронить в рублях.</Offtopic>

← →
DSKalugin © (2005-01-27 15:19) [7]

2 Danilka ©

а у нас торговля вообще без копеек. Округляемс все цены.
Типа
цена 15грн
скидка 10%=2грн :-))
итого 13грн

← →
Reindeer Moss Eater © (2005-01-27 15:22) [8]

из этого выходит лучше DOUBLE PRECISION?
Это плавающая точка. Со всеми вытекающими.

← →
Danilka © (2005-01-27 15:23) [9]

[7] DSKalugin © (27.01.05 15:19)
тогда, вообще интегер. :)
кстати, если не ошибаюсь, NUMERIC(15,2) будет храниться как интегер. Или вру?

← →
Val (from Donetsk) (2005-01-27 15:28) [10]

целым, в копейках.

← →
DSKalugin © (2005-01-27 15:33) [11]

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

← →
msguns © (2005-01-27 15:34) [12]

>DSKalugin © (27.01.05 15:19) [7]
>а у нас торговля вообще без копеек. Округляемс все цены.

Торгуем оружием ? ;)

← →
Val (from Donetsk) (2005-01-27 15:34) [13]

точные деньги - копейки.

← →
msguns © (2005-01-27 15:38) [14]

>Val (from Donetsk) (27.01.05 15:34) [13]
>точные деньги - копейки.

Ага, особенно когда торгуем п/э кульками оптом или гвоздями поштучно ;)

← →
Val (from Donetsk) (2005-01-27 15:43) [15]

>msguns © (27.01.05 15:38) [14]
пофиг. банки мои еще работают :)

← →
Johnmen © (2005-01-27 15:53) [16]

>DSKalugin © (27.01.05 15:16) [6]
>из этого выходит лучше DOUBLE PRECISION?

А NUMERIC(15,5) и есть DP, в 1 диалекте.
В 3 далекте это INT64. И не будет проблем с погрешностью разрядной сетки. Хотя такие проблемы бывают только от недопонимания...

← →
sniknik © (2005-01-27 16:06) [17]

> так точно, количество этих самых Моней :-))
не количество, а буквально
CREATE TABLE Table1 (ld INTEGER, m __Money)
(FireBird 1.5)

← →
DSKalugin © (2005-01-27 16:14) [18]

CREATE TABLE Table1 (ld INTEGER, m __Money)
???? Серьезно? лезу искать РелизНотес

← →
Vemer © (2005-01-27 16:52) [19]

Vot..

http://forum.ibase.ru/phpBB2/viewtopic.php?t=66

← →
Danilka © (2005-01-27 17:57) [20]

[11] DSKalugin © (27.01.05 15:33)
Ты на смайлики не смотри, я вполне серьезно написал про NUMERIC(15,2).
Ибо были раньше у нас суммы в Орокле, как-раз у счетов-фактур, NUMERIC(21,6), потом переделали на NUMERIC(21,2). Т.к. точность нужна до копеек. А не дя десятых или сотых долей копейки.

← →
msguns © (2005-01-27 18:41) [21]

>Danilka © (27.01.05 17:57) [20]
>Т.к. точность нужна до копеек. А не дя десятых или сотых долей копейки.

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

← →
msguns © (2005-01-27 18:43) [22]

Ой, я щас помру ;)))))))
То с геморроем облажался, теперь вот с оперденью ;))
Прошу ногами не бить,- слабый я и кашляю ;)

← →
Danilka © (2005-01-27 19:52) [23]

[22] msguns © (27.01.05 18:43)
Да, это, канечна, здорово звучит. :))
Такую гадость еще и нюхать, нет уж, извольте. :))

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

← →
Val © (2005-01-28 12:05) [24]

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

← →
msguns © (2005-01-28 13:12) [25]

>Val © (28.01.05 12:05) [24]

А как считаются проценты по дням. Округляются до копеек ? И причем здесь "документы" ?

← →
Val © (2005-01-28 13:28) [26]

>[25] msguns © (28.01.05 13:12)
1.Зачем их считать по дням, если нужно/можно считать на день последний? Конечно в итоге округяется. Или есть желание получить десятую/сотую/тысячную копейки?
2.Как это причем? на основании чего проводятся денежные операции?

← →
Anatoly Podgoretsky © (2005-01-28 14:43) [27]

Храните деньги в сберегательном банке. А как записывать в базе, дело смурное, зависящее.

← →
DSKalugin © (2005-01-28 18:31) [28]

2 Anatoly
Хoрoните деньги...
см [6] offtopic

Объясняю популярно почему нежелательно использовать NUMERIC(х,2)
Дана цена 100евро
попустим ее надо умножить на дробь 1/1.2 в каких-то целях
1/1.2=0.81300813008130081300813008130081~ в периоде общем
но поскольку точность 2 знака после запятой фактическое умножение будет на 0,81
отсюда и погрешность 2,33 евро на сотню. Т.е. 2,33%
В магазине оборот десятки тысяч. Вот и прикиньте к чему приведет такая точность

Вопрос закрыт

[28] DSKalugin © (28.01.05 18:31)
Допустим? Ну давай, друг любезный, допустим.

Допустим, есть документ "поступление товара". там есть цена, есть количество, есть сумма. Пущщай, у нас поступило 100 бурбуляторов на общую сумму 10.42рубля. то-есть, "цена" у нас будет 10 коппеек. Имеет место погрешность, какой, блин, кошмар! Да пофигу на нее. У нас что в Счет-фактуре поставщика, какие суммы стоят (про НДС помолчим, для простоты)? Я скажу какие. Там стоит:
цена = 0.10р.
кол-во = 100 шт.
сумма = 10.42р.
Точность - два знака после запятой. Таперь, обьясни мне, дураку, нафига в эл. виде заводить другую точность? Кому она нужна, бухгалтеру? Ты у него спросил? Он тебе скажет - нафиг не нужна.
Пойдем дальше, нам надо оприходовать этот товар на счетах бухгалтерского учета, так? Так. Карашо, увеличиваем кредит 41 счета у бурбуляторов на 10.42 рубля, и 100 штук. Отлично. Здесь нам тоже мегаточность не нужна. Так? Так.
Идем дальше - реализация. А давай-ка продадим 23 бурбулятора, за 5.50р.? Какие проблемы? Никаких. Выписываем Счет-фактуру. Заполняем:
Кол-во = 23 шт.
Сумма = 5.50р.
Цена = 5.50/23 = 0.2391 = 0.24р.
Это то, что у нас будет стоять в бумажном документе. И нафига нам, скажи пожалуйста, хранить другие суммы? Нифига не надо.
Теперь другой вопрос - нам надо списать эти 23 товара с 41 счета на 91 счет, т.к. реализация. Списать по себестоимости. О, блин, наверное здесь засада, наверное здесь суперточность пригодицца? А вот нифига!
Что делает бухгалтер, у которого нет супер-пупер программы? считает на калькуляторе. как он считает себестоимость?
10.42/100*23=2.3966. А на какую сумму он делает проводку? может, с точностью 4 знака после запятой? Да нихрена. Округляет он. Спроси у любого бухгалтера, если не веришь. Спишет он с 41 счета 2.40р., и 23 штуки. И оставит, соответственно, на 41 счете 10.42-2.40=8.02р. и 77 штук. А все почему? Да потому, что ему себестоимость единицы, с точностью до сотых или тысячных долей копеек - по барабану. Ему важны суммы. И когда он продаст все 100 бурбуляторов, в конце он спишет ровно 10.42р., причем, вполне возможно, что в последнем списании, себестоимость единицы бурбулятора будет 11 или 9 копеек.
А ты со своей мегапрограммой вопроешься. Так как он будет ее проверять на калькуляторе, и спрашивать - почему у тебя такая сумма, а у него такая? Он тебе так и скажет - ты че мне принес, нафига мне сотые доли копеек, я что на клоуна похож?

Я не знаю как там в банках, но во всех бумажных бухгалтерских документах точность - до копеек. А значит и смысла эти документы хранить по-другому нет никакого. И все бухгалтера считают с такой точностью. Любую операцию они округляют до двух знаков. И смотрят на тебя как на дурака, когда говоришь: "Давайте шесть знаков после запятой заведем, а?"
Результатом любого рассчета в бухгалтерии должна быть сумма, которая имеет отражение в бумажных документах с точностью до 2 знаков после запятой. Естественно, во время самих рассчетов, у тебя другая точность, но хранить в эл. виде какой-либо бумажный документ, и чтобы при этом суммы в эл. виде не совпадали с суммой бумажного документа, это нонсенс.

> нам надо списать эти 23 товара с 41 счета на 91 счет, т.к.
> реализация

мдя. на самом деле себестоимость товаров списывается в дебет 90.2 счета, а 91 счет - это прочие доходы/расходы, но это так, мелочи. :))

> Я не знаю как там в банках, но во всех бумажных
> бухгалтерских документах точность - до копеек. А
> значит и смысла эти документы хранить по-другому нет
> никакого.

а курс валюты до 4-го знака
а котировки ценных бумаг до 8-го
а в отчетах все естественно до 2-го
но недай бог на копеечку ошибится, а с такими округлениями (если все до 2-х знаков это как 2 байта об асфальт) Тут и ЦБ и ФКЦБ и прочие контролируюшие органы так заказчику вставят, что от твоей программы (а может и от тебя) только клочья полетят
В какой размерности учитывать зависит от того что учитывать.
У нас учет всей денежной массы идет в decimal(18,8)

>DSKalugin © (28.01.05 18:31) [28]

Читаем ещё раз, внимательно [3], [16]. Если недостаточно, то читаем DDG до полного просветления...:)

[32] paul_k © (28.01.05 23:46)
1. Котировки и курсы валют в официальных бумагах с какой точностью? Естественно с этой точностью их и следует хранить. Только суть их - не деньги а коэффициенты.
2. Причем здесь отчеты? Точность отчетов, вообще бывает какая угодно, и с точностью до рубля и с точностью до дысяч и с точностью до миллионов.
3. Речь идет не об отчетах, а о документах. С какой точностью сумма стоит в документе - с такой точностью ее и следует хранить в базе в электронном представлении этого документа.
4. Считать суммы следует с максимальной точностью, но когда ты эту суму пишешь в сам документ - пиши, плиз, с той точностью, с которой будет распечатан этот документ. Ибо нефиг приписками заниматься.

Простой пример. Моя любимая Счет-фактура, на их основанииведутся книги продаж/покупок. НДС - 18%, естественно получаются длинные дроби, которые суперточный чел и запишет в базу с двойной точностью, или ты в свою 18,8, так? Теперь, печатаем книгу продаж, например, где в конце необходимо написать сумму НДС.
допустим, есть у нас 2 СФ, с НДС на сумму 23.444444444р. Т.к. отчет округляется до двух знаков, то туда попадет:
23.44
23.44
теперь, итоговая сумма. Если просто суммировать по полям и затем округлять результат, то получаем: 46.89р., то-есть ошибку. Можно,конечно, ее округлять до суммирования, но нафига ее было тогда хранить с суперточностью, если она нигде не используется?

[28] DSKalugin © (28.01.05 18:31)
Мдя, сразу не заметил. Ты путаешь расчеты, со способом хранения. Считай с макс. точностью, бога ради, никто тебе не запрещает, но в результате рассчетов у тебя будут реальные деньги, которые попадут в документ и которые ты получишь от покупателя, и ни о каких миллионных долях евро речи тут уже быть не может.

Danilka © (29.01.05 10:25) [34]
допустим, есть у нас 2 СФ, с НДС на сумму 23.444444444р. Т.к. отчет округляется до двух знаков, то туда попадет:
23.44
23.44
теперь, итоговая сумма. Если просто суммировать по полям и затем округлять результат, то получаем: 46.89р., то-есть ошибку. Можно,конечно, ее округлять до суммирования, но нафига ее было тогда хранить с суперточностью, если она нигде не используется?

А надо одно из двух, либо НДС по сумме, либо сумма НДС по документам.
У нас считают так, отдельный документ, ндс по всей сумме, отчет по документам сумма этих самых НДС. И никаких проблем. Особенно учитывая, что НДС по отдельному документу может считаться из разных ставок. Соответственно в записи документа есть поле или процент НДС или уже высчитанный НДС.

[36] Anatoly Podgoretsky c (29.01.05 12:18)
> А надо одно из двух, либо НДС по сумме, либо сумма НДС по
> документам.

НДС по общей сумме всех счетов-фактур не подойдет, почему, вот простой пример:
допустим, есть две счет-фактуры, каждая на сумму 10.2 рублей, НДС 18% сверху, следовательно НДС = 1,836р. Общая сумма всех СФ = 20.2р., следовательно общий НДС = 3.672р, округляем, получаем 3.67р.
Но, реально в самих СФ суммы НДС были по 1.84р., Эти документы ушли покупателям, на их основании были сделаны проводки на эти суммы, то-есть реально по-проводкам общий НДС = 3.68р., и когда бухгалтер сверит оборотку с книгой продаж, спросит на счет потеряной копейки в последней.

> У нас считают так, отдельный документ, ндс по всей сумме,
> отчет по документам сумма этих самых НДС.

Угу, я про то-же самое и говорю, причем, если хранить НДС с точностью больше двух знаков, могут вылезти ошибки в отчете, из-за суммирования дробных частей копеек.

← →
Экспериментатор (2005-01-30 13:24) [38]

По моему на ibase рекомендуют хранить как Double precision
а уж как ты их представлять будешь для пользователя это твое дело

[38] Экспериментатор (30.01.05 13:24)
А по-моему тебе следовало-бы подтвердить свои слова ссылкой, иначе это пустой звук.
Специально зашел на ibase, и что мы видим?

Вещественные числа, в отличие от целых чисел, хранят лишь приблизительное значение, и за рубежом используются в основном для хранения научных данных. Для хранения денежных величин обычно используются целочисленные типы данных. Однако integer как правило не хватает для хранения наших денег (особенно остро стоит эта проблема в турции, где зарплату получают миллионами турецких лир). Поэтому для денег приходится использовать вещественные числа (поддержка int64 уже существует в BDE 5.x, однако в IB будет реализована только в версии 6.0).
http://ibase.ru/devinfo/round.htm

Мы видим то, что эти твои рекомендации для интербейза древнее 6 версии. Так что мимо.

Экспериментатор (30.01.05 13:24) [38]
Любой precision это число с относительной точностью. В переводе - не точное!

Как хранить деньги? :-)) Найти похожие ветки