fraksБыл еще у меня пролет, с типом данных и точностью. Завел в базе поле под вес товара. Ну и типа в граммах - куда еще точнее, пользователи все равно точнее не взвесят. Ну и сделал. А потом, когда начали работать с этим полем плотнее, обнаружился косяк. С товарами с малым весом. В частности это открытки. Попробуй задай вес одной открытки, а потом посчитай сколько будет весить 5000 открыток. Набирается большая ошибка. currency тут был бы очень к месту :)
В чем-то похожая ситуация. Программа - не бухгалтерский, а производственный учёт, какие-то сложные балансы в ней не рассчитываются, но рассчитывается стоимость изделий. В стоимость включена стоимость комплектующих, которую традиционно писали в долларах, т.к. у поставщиков и (заграничных) производителей так. При покупке, понятно, что пересчитывается в рублях. И стоимость 1 конденсатора или резистора бывает в тысячных долях доллара. Использую Currency. Продают-то их, обычно, большими партиями, сотнями или тысячами, но при расчете стоимости изделия нужно знать стоимость единицы и в БД так и хранится.

s62,
p.s. уточнил, у поставщиков цены и в уе, и в рублях, но традиционно в компании учитывали в уе, еще до этой программы. Ну это не принципиально с точки зрения типов данных, просто уточнил, чтобы не соврать насчёт цен.

Сразу не стал отвечать, т.к. у меня - частный ограниченный случай, а ТС спрашивал про общий подход к учёту финансов. Но если всё-таки ответить. Да, конечно, у учитываемых сущностей есть свойство "единица "измерения". В случае, про который я написал - это штуки. Ты имеешь в виду, что можно хранить в целых, а потом домножать на поправочный коэффициент? Типа, 1000000 для мг? Или, что можно хранить цену не для 1 шт., а например для 10 шт., 100 шт., 1000 шт.?
Вообще, Currency и хранится как целое. В БД я использую, для Firebird 2.5, тип Numeric(14, 4). Согласно документации он тоже хранится, как целое, как BIGINT. В программе использую Field.AsCurrency. Там есть некие нюансы в IBX, не буду сейчас на них останавливаться.
Тот способ, который использую я (в общем-то я насчёт хранения цен по-моему в свое время просто воспроизвел то, что было в старой БД, написанной другим человеком на Access, точно не помню, только определился с типами данных для хранения), этот способ обеспечивает требуемое хранение данных и нужные расчёты.
Если бы ввести цены например за 10 шт., 100 шт. и т.д., то тут бы появился такой момент. Что вообще с ценами на комплектующие делают в этой программе учёта? Во-первых, кто-то вводит цену, во-вторых цены могут просматривать, сравнивать, м.б. брать для каких-то внешних калькуляций, детально не знаю. В третьих цены используются для расчетов цен блоков, входящих в изделия и цен изделий. Если бы присутствовали цены не только за 1 шт., но и за 10 шт., 100, 1000, то во-первых, таких множителей наверное нужно было бы несколько. Какие-то микросхемы, микропроцессоры и стоят дорого и покупаются бывает по штукам, что-то имеет смысл мерить в десятках, что-то может быть в сотнях или тысячах. Значит и при вводе, и при просмотре нужно это отображать, а пользователю - учитывать. На мой взгляд тут - потенциальная возможность путаницы, нужно всё время смотреть - это цена за 1, за 10 или за 100. В используемом случае всё понятно - цена за 1 шт.
Если же речь - о поправочном коэффициенте, то тип Currency сам это делает, как и NUMERIC в БД.
Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. It is stored as a scaled 64-bit integer with the 4 least significant digits implicitly representing decimal places. When mixed with other real types in assignments and expressions, Currency values are automatically divided or multiplied by 10000
Про NUMERIC:
Understanding the mechanism for storing and retrieving fixed-point data should help to visualise why: for storage, the number is multiplied by 10s (10 to the power of s), converting it to an integer; when read, the integer is converted back.s - это scale, в моем случае 4.
То есть я считаю, что вот в моём случае тип Currency нормально решает задачу и без дополнительных действий по пересчёту и т.п. В случае каких-то более сложных финансовых расчётов может быть какие-то неудобства были бы, не знаю, этим особо не занимался.