Доброе время суток.
Если кто сталкивался с написанием чего-то для бухгалтерии - знает проблему округлений. Логика бухгалтера такова: каждое вычисление округляется до копеек, то есть для получения правильной с точки зрения бухгалтера суммы, например, такого выражения: (A * B + C) / D необходимо написать так:
round(round(round( A * B) + C) / D), где round - округление до 2х знаков после запятой. В общем при наличии отсутствия типа Decimal все бухгалтерские формулы превращаются в километровый кошмар.
Возникла наверняка неоригинальная мысль - хранить всё в Integer, то есть - в копейках, а в рублях - только отображать. Есть у кого-то опыт использования копеек, если есть - какая кривизна меня ждет в связи с этим, думал-думал но так и не нашел реальных препядствий.
Заранее спасибо.

конструкция с раундами очень даже выход, проблема округлений у нас была снята после поэтапного округления каждой суммы, то есть повторений действий бухгалтера с калькулятором, грубо говоря. Но конструкции дюже громоздкие получаются, хочется попробовать как-то обойти. Вот и вопрошаю... А вот currency как раз - он что может дать полезного? currency, на сколько я помню, хранит не 2 а 4 знака после запятой - опять округлять придется.
И что вообще значит - "проблема округлений" и "мягко выражаясь не решение"? В данном виде проблемы, кроме громоздкости, нет и не решение ли то решение, которое дает правильный результат именно с точки зрения бухгалтера? Думаю - как раз решение... Да и вопрос не в том.

А в копейках кто-нить пробовал хранить все-таки? В Integer? Текстовые поля, мемо, булевые и упаси Бог дату/время не предлагать.

сумма НДС однозначно не равна НДС от суммы если хотя бы одна из сумм прошла с округлением. Считать НДС от итога - абсурд. Подумайте сами, с каждой накладной, например, Вы получаете столько-то НДС, а потом в конце месяца почему-то собираетесь отменить все эти суммы НДС, содержащиеся в оформленых документах, и посчитать нечто непонятное от общей суммы сделок? Бред. Только при чем тут это?... Да, спросите у бухгалтера как он работает. Как работает и 1с, кстати. Как работают те, у кого стоит сиквель. Они используют децимал(2,0), который не превращается в хвост цифр, а округляется каждая операция, КАЖДАЯ!!! ёлы. Но в аксессе ну нет его, децимал(2,0). Если лень и бухгалтер пофигист - можно хоть вообще не округлять. Но вот у нас, например - филиалы зависят от основной фирмы, которая всё считает по-человечески с помощью сиквеля. А в филиалах аксессовские базульки, но они не имеют права расходиться в отчетах с основной фирмой. Остаётся вручную округлять каждую операцию, это ПРАВИЛЬНО, но громоздко. Вот и хочется попробовать с интегером. Неужели никто не пробовал?
Статья расходов - это только от неленивого бухгалтера с ленивым программистом. Естественно, если уж несвязуха идет - надо же куда-то списывать....

Мда. Господа, кто вам сказал что сумма НДС должна совпадать с НДС суммы? Блин... Это, конечно, частое заблуждение, но для математика тут должно быть всё ясно. То, что они не совпадают - это НОРМАЛЬНО, никто не потребует их совпадения. Итог НДС за период это сумма всех НДС отдельных документов. А общая сумма - это сумма выплат по этим документам. Они напрямую не связаны никаким процентным соотношением. Это аксиома и говорить об этом нет смысла.

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

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

Ну, функция у нас как я говорил и работает, но если уж использовать - я думаю стоит написать функции умножения и деления с округленным результатом, при их использовании вместо " * " и " / " с типом мани должно вроде быть все Ок (кстати - мани хранится как фиксед, нашел). Резюме: мани и 2 дополнительные функции должны обеспечить негромоздкие формулы и правильные вычисления.

А всё-таки, кто что знает по поводу округлений? Это что, буржуйская диверсия? Может есть какая-нить переменная screw_russian_programmers_working_with_finances установленная в ноль вместо единицы, обеспечивающая бесполезность использования встроенного округления? Или они аксесс под статистику ваяли, гады? Или в америце это округление является стандартом в отличие от России?

PS Резюме-2 : тут кажись надо вынести отдельным форумом тему "бухгалтерские расчеты" ))))))) Как-то активно всё ушло в ту степь, значит - наболело %))))

Не успел - @ВладК: а почему в сиквеле не рассматривался фиксед децимал? Я тоже нашел какой-то топик на том форуме, но кажись там кончилось тем, что резонно уперлись в децимал(2,0). У нас на сиквеле децимал используется, вполне корректно. Флоат, действительно, штука хитрая, но мани вроде как действительно хранятся не как флоат, а как фиксед, так что должны быть тоже предсказуемы (хотя проверить надо...). А вот если бы изменить принцип округления - тогда целочисленные были бы гораздо удобнее.
Самое обидоное что ни в какой литературе по аксессу я не могу найти ничего подробного ни по поводу хранения мани, ни по поводу округлений... Типа как оно есть - так и юзайте...

@ Savik - Есть прихоти заказчика, а есть правила. В том числе правила округления в финансовой отчетности. А то так получается что для себя - это хоть goto пиши... К тому же вопрос не в принципах округления, тут может быть только правильно и всё остальное, а в том, как хранить данные. Или код программы по-вашему тоже предоставляет заказчик?

@ДиД - может Вы в курсе по поводу правил округления аксесса? Это непобедимо?

Ясно. Собственно - так и делаем...
Значит использование интегера особого смысла не имеет, а функции округленного умножения и деления при имеющейся функции округления сварганить несложно...
Остался один вопрос - мани ТОЧНО хранится как фиксед? Боюсь я этого аксесса...

на раунд не жалуюсь тчк
просто он округляет статистически зпт
а мне нужно математически тчк

за мани спасибо тчк