Почему в 1С нельзя создавать реквизиты с числовыми значениями с плавающей (float) запятой?

А зачем?

лучше мнимые... чтобы 2+3 <> 3+2

2(0) во всех четырех СУБД они есть?

Патамушто 1С это замена счёт и карандашика с блокнотиком для бухгалтерши и кладовщика.

(0) думаешь 15,3 в 1С храниться как Integer ?

(5) думаю да, ибо

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt

SQL defines distinct data types named by the following <key word>s:
        CHARACTER, CHARACTER VARYING, BIT, BIT VARYING, NUMERIC, DECIMAL,
        INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION, DATE, TIME,
        TIMESTAMP, and INTERVAL

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

(5) для нас-то это все равно 2 (10) разрядов до, 3 разряда после.
А плавающее подразумевает гибкое заполнение разрядами обе матрицы.

не смогут потому что.

2(5) в ДБ2 вроде как Децимал

(5) (6) Откуда свалились?
Че, лень в SQL базу залезть?

(7) как раз для расчета денег это и нужно в первую очередь. А уже в инженерных расчетах для экономии места - во-вторую.

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

(5) ты числа с фиксированной и плавающей запятой различаешь?

(5), (6) - оно там как DOUBLE PRECISION

(11) эээ (6) было к (3) прошу прощения

(11) не лень, уже лезу

Лазать не надо.
Numeric там

(2) не понял, как связаны мнимые числа и целые "2+3 <> 3+2"

(18) не может быть SINGLE. Должен быть Дабл... 1С с 8-ки об этом трезвонит...

(12) Это где это доли копеек считаются. Я по наивности всегда полагал что в современном мире копейка минимальная денежная величина.

(18) поздняк метаться,
numeric увидел

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

(21) в расчетах после запятой остаются не два знака, а все - вплоть до последнего разряда.
А в 1С где только можно выравнивается вручную до 2-го знака. Поэтому один и тот же расчет - но по разным алгоритмам, - дает разный результат. И чем чаще делается расчет, тем больше разность.

Имхо нафиг они там нужны. А про ушлых программистов - нужно нормальных искать и не ставить задачи поиска квадратного корня в НДС

в 1С можно хранить не только бухгалтерские записи. шифрование может требовать заведомо больших чисел, а физические параметры могут быть точнее.

(23) как раз в 1с это и не учитывается - после 2-го знака. Примеров - масса, когда НДС тот же не сходится. И везде понатыкано округление, причем везде разное...

(27)[Примеров - масса, когда НДС тот же не сходится. И везде понатыкано округление, причем везде разное.]
не гони

(24) Так то в процессе, а в сабже про реквизиты сказано где результат фиксируется. Если он будет с неопределенным количеством знаков после запятой тупо сравнивать заколебешься. Одно и то же с виду число округленное до пары знаков в печатной форме при разных способах его получения будет отличаться внутри реквизита и результат сравнения будет несколько неожиданным.

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

(0) если исльно надо - храни m и n из m/n

(28) не гони сам.

2(28) да не, пусть гонит, сегодня день такой, что похоже можно...

(30) Дело не в сложности алгоритмов. Числа с плавающей точкой тупо нельзя сравнивать на равенство, только на больше/меньше.

(29) так его и не надо округлять, а хранить полностью. А округлять - только для вывода документов. Но не для расчетов.
Эта проблема - когда и как округлять, чтобы доки сходились, стоит уже давно и задолго до 1с.

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

2(36) тихо-тихо, нельзя вот так резко срывать покровы...

(33) если НДС считаешь по ТОМУ ЖЕ САМОМУ алгоритму, как в 1С (прыгаешь по всем функциям) - то сойдется (а как иначе, если округляется и неокругляется все время одинаково). А если сам подсчитаешь НДС (тот же самый, формула-то одна) - будут отличия уже. И чем ботльшле количество - тем больше отличий.
А это только один из примеров.

(38) [А это только один из примеров.]
нет примера,
есть голословный гон

(35) А взаиморасчеты у нас в чем идут, в рублях/копейках или в грошах тоже? А вес как считается, до грамма, или в наноединицах? Сам смысл расчетов предполагает работу с округленными данными. Можно и флоатами хранить, просто везде и всюду придется Окр() ставить. А когда где-нибудь забудешь, а забудешь обязательно ошибка может выйти совсем не в доли копеек от неверно отработавшего условия. И хрен эту сволочь потом найдешь.

2(38) зачем ты написал (33)? чтобы твою мысль услышали голоса в твоей голове ее можно просто думать.. даже на форуме писать не обязательно...

(36) вы им еще типовой расчет 1с предложите использовать для такой работы, со всеми типовыми функциями расчета НДС :)

(40) чем больше точность - меньше ошибка. А в 1С точность фиксирована навсегда.

(41) а у вас, вижу, голоса никак не сойдутся вместе....

(43) Иди в магазин и попроси взвесить тебе 1кг. 150,3598761гр. огурцов

(43) Да с фига она меньше-то? От поставщика к тебе накладная придет где НДС с точностью два знака. Покупателю такую же дашь. Какой смысл его хранить с большей точностью? Речь-то о реквизитах, в расчетах никто тебя по точности не ограничивает.

(40) насчет веса. Пример 2:
если учитывать кг, но не учитывать граммы - как в 1с реализовано, то на конец месяца куча граммовых остатков фиксируется.
Или тот же перевод из коробок в тонны - в кг - потом в паллеты.
Пересчет отнимает накладные расходы (те самые неучтенные "нанограммы"), которые в результате выливаются как потери товара при пересчете.

(46) производство и расчет НДС - это не только "получил - продал".
НДС насчитывается по сложной схеме по конечному продукту.

(31) индексировать такое печально

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

(50)[а не с точностью до тысячных, хотя бы.]
ржал
от души
пиши ещё

так-так... в магазинах стало быть не вешают, а в 1С будем учитывать... ну чтобы магазин на учет не закрывать... наверное...

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

(50) В магазинах точность весов минимально влияет на складкие запасы. На первом месте - воровство, на втором естественная убыль.

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

(26) Шифрование с числами с плавающей запятой не работает вообще.

(38) Какой-такой алгоритм? Надо просто n-е количество чисел сложить.

(47) Если пользователь идиот - это не лечится. Если надо работать с граммами - заводите единицу хранения остатков граммы. Как на весах в цехе.

(48) Вычислить 18% от суммы - это сложная схема? Ну вы, блин, даете...

(56) >Вычислить 18% от суммы - это сложная схема? Ну вы, блин, даете...
вот и сравните расчет "18% от суммы" с расчетом 1с через ЦеныИВалюты.

Даааа... НДС в сумме и НДС сверху это пипец какие алгоритмы. Перельман над ними десять лет бился. Ему не за решение этой задачи премию присудили?

(58) Ну это смотря какой НДС конечно... Если речь о расчете НДС к уплате там и правда пипец, надо учесть НДС исходящий и входящий с учетом фактур, и не дай бог еще и поставщики нерезиденты попадутся... Впрочем 1с-кин вряд ли так глубоко копал, он видимо о том что сумма НДС по строкам документа отличается от того что выйдет если вычислить его от общей суммы дока. Только ничем тут увеличение точности не поможет. В печатной форме он все равно не будет сходится.

с учетом фактур = с учетом фактур на аванс

(59) я про то, что либо алгоритмы должны быть идентичными, либо - увеличивать точность расчета. А т.к. точность нельзя увеличивать бесконечно, плавающая запятая в этом помогает.
Вот еще пример.
Для расчета зарплаты потребовалось увеличить точность после запятой до 10-го знака. Уговорил до 6. Точность до третьего знака (так любимая 1с-никами) дает расхождения в рубли/на человека.
А это уже не расчет, а фигня :)

(61) ну и как ты вернешь .001 рубля человеку? точность до 3-х - для единиц хранения, точность до 2-х - для денег. и правильно, потому как вернуть/заплатить меньше минимальной единицы невозможно

(61) помню, у нас то же были как и у вас полностью долбанутые, при инвентаризации гвозди и шурупы считали поштучно. И тоже что-то говорили про расчет. Ну кому сейчас нужно сидеть выверять до рубля? И держать лишних 2х-3-х бухгалтеров, которые съедают 100000 денег фирмы ежемесячно?