Доработки Разрядность (количество знаков)

ПРЕДЛАГАЮ 'I': организовать настройку разрядности (то есть, количества знаков после запятой) для каждого типа данных отдельно. Например, мои персональные настройки выглядели бы так, исходя из имеющихся основных типов данных: "Сумма", "Остаток", "Цена", "Количество", "Валюта". Для каждого типа данных нахожу достаточно аргументов, чтобы применять "свое" количество знаков после запятой. "Сумма" обычно 2 знака (этого достаточно для учета). "Остаток" - аналогично. "Цена" обычно от 2 до 4 знаков (4 - для дешевых позиций, которые могут продаваться упаковками, а могут и в розницу). "Количество" 0 знаков (по-моему, "цельных" товаров, услуг встречается больше). "Валюта" до 6 знаков (некоторые валюты банки оценивают за 100 или 1000 единиц и т.п.).
 
Предполагаю, что возможно и альтернативное решение этой же задачи, путем ограничения максимально допустимого числа разрядов. Вводимые в рабочие поля данные сохранять с таким количеством разрядов, сколько знаков после запятой было реально введено в это поле данных. При этом, оставшиеся до разрешенного максимума, "неиспользованные" разряды (обычно автозаполняемые "0"), не отображать. А для значений поля "Количество", использовать дополнительную настройку разрешающую применять в учете дробное количество.

Давайте разложим по полочкам:
 
1. "Сумма" операции и "Остаток". Эти величины задаются во вполне себе конкретной валюте. Соответственно, разрядность для этой валюты можно указать на закладке валют. Тут все просто.
 
2. "Цена" даже не хранится, она вычисляется на лету. Просто сумма операции делится на количество и мы получаем цену. Цена выражена в той же валюте, в которой ведется сам счет, соответственно, цена показывается с той же разрядностью, что и "Сумма" и "Остаток". Вроде логично.
 
3. То что Вы назвали "Валюта" вроде бы как является курсом пересчета одной валюты в другую. На самом деле для корректного пересчета с минимальными ошибками округления (а это самое главное в задании курсов) прекрасно подходит имеющаяся ныне система представления курсов валют. Попробуйте ввести вручную курсы любых двух валют и посмотрите, как устроен диалог ввода курсов. Для существующего представления курсов валют нет нужды увеличивать разрядность представления курсов.
 
4. "Количество". Ну не всегда 0 разрядов - лучшее решение потому что можно купить и поллитра молока и полбуханки хлеба. Делать дробное количество... А зачем? Вообще, AbilityCash не предназначен для складского учета.
 
И еще одно: для представления денег в AbilityCash используется 64-битное целое, при этом 4 младшие десятичные разряда используются для хранения копеек и сотых долей копеек. Другими словами, берем целое значение, переводим его в десятичную систему счисления, отступаем справа 4 разряда и ставим перед ними запятую.
 
Такое представление широко используется для хранения денежных сумм в программном обеспечении. Оно позволяет избегать ошибок округления, использовать быструю целочисленную арифметику, позволяет производить вычисления без необходимости приводить разрядность одной валюты к другой. Такой подход отлично работает в AbilityCash на протяжении многих лет. У него есть всего один недостаток: разрядности не хватает для представления ПИФов. В остальном все работает прекрасно.
 
Нужно ли дорабатывать то, что и так работает хорошо?

Начну с мысли в слух: "если не хочешь читать длинные ответы, не пиши длинные вопросы...". Похоже, я попал... Теперь, моя очередь писать ответы. ;-)
 
Я обязательно напишу. Но мне потребуется время.

Ответ написал. Но какой-то он длинный получился. Могу направить его электронкой? А то, как-то много места он займет на сайте...

Ценность этого раздела состоит в том, что все предложения и доработки находятся в едином месте. И когда я выбираю очередную доработку, которую буду реализовывать, мне не нужно рыскать по электронной почте в поисках нужного. Да и другие пользователи видят.
 
В общем, лучше сюда. Место на сайте - не жалко.

Ну, собственно, "хозяин - Барин". На то, он и хозяин. Снова отредактировал свой вариант ответа. Вырезал все часть лирики, оставил максимум лирики по сути и выкладываю. Если что-то по контексту не пляшет, то прошу "пардона".
 
Ответ от 23/07/14 (выборочно):
При всем моем желании быть кратким и лаконичным, мне кажется нереальным таковым быть при обсуждении данного вопроса. Сделанное мной предложение, начатый спор (в нормальном смысле слова), требует определить условия такого спора. Конечно же, что мое предложение обусловлено моим видением вопроса. К сожалению, я никак не мог учесть точку зрения и задумку автора программы. Достаточно много я могу предполагать, но, не зная деталей проекта и целей, невозможно что-то толково «вырисовать» (имеется ввиду, предложить).
 
<вырезано>
 
Вступление.
Здесь уже также перехожу на полные или частичные ответы на #305 тему раздела ДОРОБОТКИ вашего сайта. Так вот, ваша программа задумывалась как программа «учета личных средств». И, я собственно не следил за историей становления программы, что дало бы, наверное, больше деталей и объяснений для моего взгляда. Но, это и к лучшему, я оцениваю только последнюю версию – результат. И делаю это своим «взглядом со стороны». Надеюсь, взгляд будет трезвым. Конечно же, с точки зрения планировавшегося функционала, я буду многого «не знать», а чего-то очевидного даже не видеть прямо «перед своим носом». За что сразу прошу прощения, и прошу не утруждать себя слишком детальными разъяснениями (чтобы не тратить ваше время). Возвращаемся: ваша программа задумывалась как программа «учета личных средств». Но мне кажется, что она (последняя версия программы) вполне отвечает требованиям и материального учета (точнее, какой-то его части). Наверное, это произошло тогда, когда в функционале появились поля «Цена» и «Количество». Итак, получается, что такой цели не ставилось, но она уже как-то реализована. Можно сказать и по-другому, я решаю свои задачи, более относящиеся именно к материальному учету, и не имею дискомфорта. Однако, имеется дискомфорт в отношении некоторых моментов, к которым я более привык, или которые, мне кажется, можно было бы доработать, с точки зрения человека-перфекциониста. Но это уже «добавочные вопросы», так как ваша программа - готовый продукт. Прислушиваться к моим пожеланиям нет нужды. Но, если у вас появится мысль, что предложение может «иметь место быть», надеюсь вы сильно возражать не будете читая это и или подобные «предложения». Ради этого я собственно и затеял общение.
Идем по вашим пунктам ответа темы #305 (ДОРАБОТКИ).
 
1. Мое видение разрядности данных сложилось в ходе выполнения рабочих задач связанных с моим бизнес-процессом. Программе «учета личных средств» достаточно двух знаков после запятой для полей данных «Сумма» и «Остаток». Здесь моя точка зрения совпадает с вашей. Как, собственно, и для вероятных функции «материального учета», аналогичных полей. Но почему настройка разрядности валюты задает разрядность для данных полей, связи не вижу. Здесь более не о чем говорить. Только отмечу, что ставить больше двух знаков в таких полях, означает портить внешний вид отображаемых результатов. Иногда, конечно и такая необходимость есть (видеть больше двух знаков в суммах).
2. То, что цена вычисляется на ходу заметно. Соответственно, это похоже на следствие того, что поля «Цена» и «Количество» не планировались при задумке функционала программы. Соответственно, их последующее внедрение дает не очень гармоничный результат. То есть, с одной стороны, «Цена» и «Количество» - промежуточные величины, которые только (!) визуализируют данные программы «учета личных средств». Но, из-за того, что они могут отображаться некорректно (в некоторых, редких случаях!), с другой стороны, они смазывают (портят) эффект упомянутой визуализации. То, что цена вычисляется на лету проблемы нет. Вопрос в отображении промежуточного результата вычисления. Ведь он не влияет на итоговый результат: «Сумма», который все равно будет с двумя знаками. Это же промежуточное «значение», и какое количество знаков промежуточного значения я буду видеть, ни на что не влияет. Кроме ситуации, когда  «Цена» единицы окажется слишком мала для количества видимых знаков. Понятно, что можно найти компромисс: внести данные так, чтобы получить красивое отображение. Учитывая такой подход, обсуждение вопроса количества знаков для «Цены» теряет смысл. (см. также примеры в пункте 4)
3. Да, под «Валютой» я имел ввиду курсы валют. Здесь мое мнение основано на теории. Поэтому, не имеет смысла подводить базу под мое мнение. В любом случае вопрос не задавался с целью повлиять на способ расчета. Вопрос мог бы сводиться к количеству отображаемых знаков, но в уже созданной, отлаженной и главное работающей программе он также теряет актуальность. Большинство пользователей никогда не обратят внимание на форму реализации. Кстати, решение вопроса многовалютности (в любом учете) - очень серьезная задача. Для себя я решил, что учет должен вестись в одной валюте (все записи базы, при создании, приводятся к валюте учета, курсы фиксируются в примечании). Соответственно, сделал настройку и в вашей программе. Поэтому, оценить диалог курса валют не смогу (боюсь потерять данные).
4. «Количество» - единственный вопрос, где я не соглашаюсь. Здесь кое-что зависит от способа ввода данных каждым пользователем. «0» разрядов для такого поля – норма. На основе вашего примера: «молоко» и «хлеб». Поллитра молока будет статьей расхода «молоко». Полбуханки хлеба будет статьей расхода «хлеб». Разница будет в сумме. Пример записи:
22/07/14 Статья расхода «Хлеб» 1 5,00 руб
25/07/14 Статья расхода «Хлеб» 1 2,50 руб
 
При желании, корректируется статья расхода, например:
22/07/14 Статья расхода «Молоко» 1 5,00 руб
25/07/14 Статья расхода «Молоко, 0,5л» 1 2,50 руб
25/07/14 Статья расхода «Молоко, 0,2л» 1 1,75 руб
 
Аргумент, для такой формы записи простой. Если покупать две упаковки по «поллитра молока», то это необязательно будет стоимость одной литровой упаковки. Хотя, возможно, что молоко реализуется на разлив, тогда будет. Детализировать статью также можно и в поле «Примечание».
 
Теперь привожу пример, который дает повод задуматься. Снова оговорка, что аргументация данного пункта практически потеряет силу, если вы скажете, что программа создавалась для «учета личных средств». Я исхожу из того, что использую существующий и удобный для отображения записи интерфейс с полями «Количество» и «Цена». Это реальный пример. Я купил конденсаторы в количестве 100 тысяч штук (упаковки по 10 тыс.) за $215. В итоге вижу такую запись:
 
22/07/14 Конденсатор -215,00(Сумма) 0,00(Цена) 100 000,0000(Количество)
 
Конечно, я могу записать по-другому:
 
22/07/14 Конденсатор, уп-ка 10 тыс.шт -215,00 21,50 10,0000
 
Теперь, я захочу продать 5 шт. Строку данных даже не буду приводить. Понятно, что суммы «учета личных средств» никак не пострадают. Но, вот промежуточные цифры, будут выглядеть как-то не очень. То есть, в моем понимании, теряется удобная функция визуализации данных. Причину этого вижу именно в невозможности контролировать, регулировать количество знаков после запятой. Например, привожу пример отображения данных в лояльном виде:
 
22/07/14 Конденсатор -215,00(Сумма) 0,00215(Цена) 100 000(Количество)
 
Конечно, можно отказаться от использования полей «Количество» и «Цена», отключив их в настройках. Тогда эти данные полезут в «Примечание». Снова , это будет не очень красиво.
 
Вывод.
Складывается впечатление, что мы поговорили «каждый о своем». Вы про нюансы программирования. Я про отображение данных. Соответственно, вопрос в вашем комментарии для меня приобретает риторическое значение: «Нужно ли дорабатывать то, что и так работает хорошо?». Конечно, не нужно. Кстати, а вы уже поставили точку, или возможно появление очередной версии программы?