создать новую тему раскрыть все
свернуть/развернуть ветвь Начисление % [UicraorWolf 10/11/2012 05:18] # написать ответ
 
Здравствуйте - очень понравилась программа - очень хочется увидеть такую функцию как начисление процентов - простого и сложного. остальное вроде идеально)
свернуть/развернуть ветвь 100% [заяц 10/11/2012 06:55] # написать ответ
 
вам предложат оформлять это отдельной опирацией
свернуть/развернуть ветвь как это? [UicraorWolf 10/11/2012 12:57] # написать ответ
 
что это значит? в примерах можно?
свернуть/развернуть ветвь самому посчитать % [Lamerrrr 10/11/2012 22:31] # написать ответ
 
типа... и внести в соответсвующую статью. я так и делаю. автоматизировать было б прикольно, но другой раз как сталкнешся с каким нить хитровумным начислением, что понимаешь, насколько попытка охватить все возможные варианты сложна.
свернуть/развернуть ветвь ну, [пацак].[ 11/11/2012 23:43] # написать ответ
 
опять за свое.
Вопрос с начислением процентов настолько прост и настолько сложен, что формализовать его невозможно. Можно, конечно, разработать какой-то формализованный подход, что несомненно приведет к появлению уродливого нароста на этой стройной программе.
Попробую пояснить.
Например, проценты на депозит. Даже простые проценты каждый банк начисляет, как ему удобно. Знаю большие банки с тысячами отделений по стране начисляют премию на депозит каждого 25-го числа. В 18:00 заходишь на сайт - проценты появились. Есть банки, которые начисляют премию в последний рабочий день месяца. Есть банк, который насчитывает проценты даже заранее, до окончания месяца. Но сумма становится активной в 23:59:59 последнего дня месяца и доступна в следующий рабочий день после окончания месяца.
Другими словами, программа помимо всего прочего, должна знать а. календарь рабочих дней (в разных странахTo wink, б. методику банка. Если сделать, чтобы она считала тупо % на последний день месяца и это не будет соответствовать реальной сумме на счете в банке - мне такая автоматизация не нужна.
То же самое со скидочными (бонусными) процентами. Скажем, некоторые магазины дают скидку выборочно, на локальные продукты - да, на колониальные продукты - нет. То есть, скидка не всегда равна проценту от суммы чека.
Скидочный % может изменяться в зависимости от накопленной суммы покупок в данном магазине - 5%, 7%, 10% и т.д. Программа должна отслеживать ваши покупки в данном магазине и знать схему скидок данного магазина. Вы сами то можете формализовать все варианты своих покупок. Думаю, что нет. Что же тогда делать программисту с реализацией этой автоматизации.
Я бы напомнил в связи с этими процентами о другой "фиче", которая озвучена была ранее и даже планировалась в реализацию. Но до сих пор не сделана. Это запоминание/отображение формулы в окне суммы операции (очень похоже на свойство ячеек Excel). Сейчас поле суммы работает как калькулятор - набиваете арифметическое выражение, давите на знак = и получаете сумму. Очень удобно.
А, если бы формула запоминалась, - берете старую операцию с формулой, создаете новую операцию дублированием и правите нужные операнды, давите на =, и - счастье.
свернуть/развернуть ветвь Зачем??? [latan 12/11/2012 03:57] # написать ответ
 
Попробовала представить формулу в поле суммы операции... Ничего кроме какого-то кошмара так и не предстало перед глазами!
 
Как, по-Вашему представлению, должна выглядеть формула в поле суммы? Например, (a+b)/c*d/e*f%? Ну, и много информации Вы почерпнёте из этого, когда создадите новую операцию путём дублирования? Или где-то отдельно, на бумажечке, держать памятку, что такое a, что такое b и т.д. А потом аккуратно подводить курсор и вместо переменных менять буквы на суммы и другие числа - параметы формулы? Но в следующий раз уже при дублировании формулы-то не будет.
Или хранить формулу не в переменных, а сразу в числах? Ну, например, подставим: (100+150)/8*25/12*7%. И что, это понятнее будет через месяц, например, когда понадобится сделать дубль такой операции?
Я уж не говорю о том, что открыв операцию, хорошо бы всё-таки видеть её чистую сумму, а не непонятную (или забытую) последовательность математических символов.
 
В общем, формула в поле вместо реальной итоговой суммы мне видится абсолютно инородным телом, которое никак не "лезет" в программу.
Единственный вариант, который, на мой взгляд, ну хоть как-то объясним и приемлем с точки зрения целесообразности формул, это если бы были составные операции. Т.е., сложные операции, которые состоят из нескольких простых. И при этом самые простые формулы. Например, составная операция из 2 простых: 1 часть - вводим как обычную операцию с конкретной суммой, 2 часть - какие-то арифметические действия с суммой из 1 части (та самая формула).
Но сколько при этом возникает побочных вопросов, связанных и с реализацией, и с интеграцией этого варанта в программу! Честно говоря, лень даже пытаться их сформулировать.
 
Так что, никого не хочу обидеть, но мне кажется, кому не хватает формул в программе, это - к Биллу Гейтсу. У меня у самой впридачу к AbilityCash есть 3 Excel-файла, в которых я делаю необходимые расчёты (в том числе, и прогнозные), а из них нужные суммы заношу уже в программу в виде операций.
 
...уважаемый пацак меня опередил. Мне нечего добавить к сказанному.
 
Может быть этот текст в FAQ переместить?
 
Для форума сойдёт, а для FAQ слишком небрежно.
свернуть/развернуть ветвь затем [пацак].[ 12/11/2012 15:54] # написать ответ
 
попробую без какого-то кошмара перед глазами пояснить на примере.
Прекрасно обхожусь без запоминания арифметической формулы в поле суммы. Формулу забиваю в комментарий. При создании операции на следующий период дублированием старой просто корректирую формулу в комментарии, копирую ее в поле суммы, давлю на =, и получаю результат. А формула в комментарии вызывает не ужас а полное ощущение счастья. На вскидку - пример формулы : ("текущие показания счетчика" - "предыдущие показания счетчика") х "тариф". Применяю в операциях платы за электроэнергию, горячую воду, холодную воду. Чем хорошо - всегда перед глазами показания счетчиков и тарифы (которые имеют тенденцию часто неоправданно изменяться в сторону увеличения).
Не знаю, кто такой Билл Гейтс, но Excel, который помнится не он придумал, использую. Сколько файлов, точно не скажу. Один из них, например, для создания комментариев к платежкам (через интернет). Excel чудесно справляется, создавая комментарий с таким обязательными  параметрами : назначение платежа, период, личный счет, фамилия. адрес и пр. И. что очень важно, количество символов в комментарии не должно превышать определенное значение. Есть и другие примеры, но не суть.
свернуть/развернуть ветвь Правильно [latan 13/11/2012 11:58] # написать ответ
 
Сейчас единственный вариант - написать формулу в поле примечания. Тоже хотела об этом сказать, только забыла.
 
Но Вы ведь писали:
"запоминание/отображение формулы в окне суммы операции (очень похоже на свойство ячеек Excel). Сейчас поле суммы работает как калькулятор".
Я поняла, что Вы предлагаете заменить отображение в поле суммы итогового числа на формулу. А я по образованию математик и очень трепетно отношусь к формулам и результатам их вычисленийWell
И если уж говорить об Excel'е, то там формула и её результат показываются в 2 разных местах: формула - в строке формул, а результат её вычисления - в ячейке. И я никак не могу себе представить, как это объединить в одном месте. Вот и Вы формулу в приведённом коммунальном примере держите в примечании, а результат - в поле суммы.
свернуть/развернуть ветвь не крепко спал [пацак].[ 14/11/2012 13:37] # написать ответ
 
в связи с затмением солнечным, думал за жизнь.
И пришел в голову алгоритм переключения в поле суммы операции между суммой и формулой, которая эту сумму производит.
Скажем, ввели в поле суммы формулу, нажали "=", получаем сумму. Если еще раз нажать на "=", снова появится формула. То есть, кнопка "=" работает как триггер.
При открывании старой операции в поле суммы всегда сумма.
Если в поле суммы формула не вводилась, при любом нажатии на "=" всегда высвечивается сумма.
Если раньше была формула, то после насильного ввода суммы, формула удаляется, остается только сумма.
Такой вот алгоритм. Абсолютно не требует каких-либо изменений в интерфейсе программы.
Может быть, пригодится.
 
Ладно интерфейс - это вопрос решаемый. Хотя автор тут уже, по-моему, неоднократно говорил о проблеме перегруженности интерфейса. Правда, возникает вопрос - каким по форме и размеру делать поле для формулы на экране? Таким как примечание? Но тут уже некоторые жаловались на то, что примечание не полностью видно. Но это примечание, Бог с ним, не критично, а вот если виден только кусочек формулы, то какая от такой формулы польза? Да и неудобно пользоваться, на мой взгляд. Тогда что, делать поле для формулы на экране достаточно большим? Насколько большим? В приведённом выше "коммунальном" примере всего-то 3 переменных, 2 скобки и 2 знака арифметических операций, а длина формулы получилась - ого-го. На какую длину формулы нужно расчитывать? Естествнно, на произвольную (как примечание). Но где размещать поле с формулой произвольной длины? Если в том же поле, что и сумма с дополнительной кнопкой переключения - будет полностью не видна большая формула. Если в отдельном поле - опять приходим к проблеме перегруженности интерфейса.
 
Что ещё? Ну ещё добавить нужно внутрь базы новое поле для формулы... Поле произвольной длины, как примечание. При этом размер базы данных увеличится... Я, кстати, всегда, когда "рекламирую" AbilityCash своим знакомым, в качестве большого плюса говорю об очень компактной по размеру базе данных. Остаётся надеяться, что реализация формул не приведёт к разрастанию базы.
 
Кстати, добавление нового поля в сущестующую базу данных - это дополнительные трудозатраты разработчика на реализацию корректного перехода на новую версию. Ну чтобы в уже существующих операциях не попортить что-нибудь. А это время. И верятность ошибок. И опять время на их исправление.
 
А как быть с функциями? Например, с округлением? Где гарантия, что в жизни реальные суммы всегда получаются по правилам математического округления? Пример, та же коммуналка. По тарифам суммы получаются с копейками (а есть у нас такие тарифы, что и с десятыми долями копеек). Но когда приходишь платить в банк, то там или недодают сдачу, или "прощают" отсутствие мелочи. Вот такое округление. А однажды у меня был случай, когда "зарплатный" банк вдруг в банкоматах перестал проводить операции платежей с копейками. Только в целых рублях. В другой раз вдруг перестали проводить операции оплаты мобильной связи на суммы менее 10 руб.
 
Так вот это я к чему. Даже простейшая функция округления в чистом виде не всегда даст результат, совпадающий с реальным. Значит, пользователю в свою формулу нужно будет добавлять некую дельту. Ну и зачем мне такая формула, которая даёт приблизительный результат? Лично мне - незачем.
 
Далее. Округление - это как бы "внутренняя" функция. Оно должно выполнятся автоматически при подсчёте результата формулы, пользователь не должен ничего добавлять в свою формулу, чтобы произошло округление полученной суммы до 2 знаков после запятой. Но даже здесь возможны варианты. Можно округлять при выполнении каждого действия, а можно округлять только конечный результат вычислений. И суммы при этом зачастую получаются разные. Каким способом делать округление - решать разработчику. Но удовлетворит ли выбранный им вариант всех пользователей - неизвестно. При этом нужно помнить, что, например, курсы валют имеют не 2, а 4 знака после запятой.
 
Ну, а потом (есть у меня какое-то нехорошее предчувствие) кто-нибудь захочет, чтобы в формулах можно было использовать какие-нибудь дополнительные готовые функции Not precisely
 
В общем, если автор всё-таки нацелился на реализацию ввода и использования формул в операциях, будет очень интересно посмотреть, как это в конце концов реализуется. И пожелать успеха.
 
А вообще, пока писала, поняла, что за 2,5 года пользования AbilityCash настолько сроднилась с программой, что "болею" за неё, как за своюVery we!