Отправляет email-рассылки с помощью сервиса Sendsay

За 2004-10-28

[abilitycash] |dervish.acash| Ошибка и пожелания 002.004

Еще предложения
Действительно, ошибки ни какой нет. Это я не опонял. И действительно прав <b>MrCricket</b>.Именно
это меня сбило с толку. Он же предложил понятные называния, но длинные. Их в
этом месте неудобно будет вставлять.
Предложение такое. Т.к. переводы бывают 2х видов \"расходные\" и \"приходные\"
нужно как-то это испльзовать. Например: \"перевод-расход\" и \"перевод-приход\"
или \"приходный перевод\" и \"расходный перевод\" по аналогии с ордерами.

Или что-нибудь типа \"входящие переводы\" и \"исходящие переводы\":).

>>...я постараюсь реализовать один общий для всех контролов подход.
Сам, как программист, знаю, что общие подходы реализовать трудно. Замахнешься,
а потом то там, то сям, то времени не хватает.
Может быть лучше сделать, как можно проще, а уже потом все это подвести под единую
основу. <i>Это только предложение. Не поймите меня неправильно</i>

   Илья 2004-10-28 20:40:58 (#252741)

[abilitycash] |dervish.versions| Очень хочется малую опцию добавить. 002.003

Было бы неплохобы
Что бы очередной периодический платеж, не сделанный вовремя, появлялся АВТОМАТИЧЕСКИ
сам как долг.

   2004-10-28 14:18:09 (#252478)

[abilitycash] |dervish.acash| Количественный учет 009.010

По поводу графиков
Если планируется возможность изменения цвета графиков, и не только цвета, пользователем,
тогда вопрос снимается. В настоящее время вид графиков очень разнообразный. Нет
единства стиля, как мне кажется.

   Сергей 2004-10-28 07:05:48 (#252199)

[abilitycash] |dervish.acash| Ошибка и пожелания 002.003

Предложение по чекбоксам
Мне кажется, одна из причин двоякости заключается во множественном числе слов
<<счета/счетов>> - ведь если я выбрал только один счет, то <<Перевод на счета>>
наталкивает на мысль о <b>переводе с моего выбранного счета на другие счета</b>,
что есть неправильно. Аналогично и с <<Перевод со счетов>>.

Я бы предложил переименовать чекбоксы в <<Перевод на выбранные счета>> и <<Перевод
с выбранных счетов>>, либо просто <<Перевод на>> и <<Перевод с>>. Кривовато,
конечно, зато информативнее.

   mrcrick***@w*****.ru 2004-10-28 04:38:22 (#252179)

[abilitycash] |dervish.bugs| Проблема при экспорте импорте. 002.003

Импорт (194,195)
При экспорте <b>только операций</b> в файл xls и при их последующем импорте --
в импортированных операциях теряются значения пользовательских категорий (хотя
в файле xls присутствуют).

   mrcrick***@w*****.ru 2004-10-28 03:04:41 (#252163)

[abilitycash] |dervish.versions| быстрая сумма как в экселе 000.001

быстрая сумма как в экселе
Есть предложение: сделать по принципу, применяемом в экселе - чтоб в статусной
строке внизу окна в рельном времени показывалась сумма по выделенным в текущий
момент времени операциям.

   starush 2004-10-28 01:52:23 (#252133)

[abilitycash] |dervish.acash| Стандартные операции 013.014

Ох, вещь полезная, но реализуется, по идее,
всегда с трудом. Например, подсчет прибыли за некий период можно сделать \"вручную\",
но это каждый раз пределывать, если какие-то данные были искажены - скушно до
ужаса. Или для разных периодов - все повторять. Формула, тем не менее вполне
очевидна: в каждом отчетном периоде брать сумму оборотов по счетам прихода, вычитать
из нее сумму оборотов по счетам расхода, а эту разницу зачислять на счет \"Прибыль\".
Если пользователю надо подставить неизвестное значение, но программа может его
подсчитать - это же старая добрая процедура-функция. Если технически разрешимы
подстановки не просто числовых параметров, а функций, то все понятно? Можно ли
решить задачу в самом простом варианте (уже вне ввода шаблонов): при зачислении
на некий счет иметь возможность получения суммы прихода не по формуле, намертво
забитой (количество*цена), а выбрать вариант работы с введенными Вами функциями?
Что-то типа \"ОБОРОТ(сч1,дата1,дата2) - ОБОРОТ(сч2,дата1,дата2)\" (Черточка внутри
есть знак МИНУС). Наличие даже одной этой возможности ускорило бы процесс заполнения
базы. Подразумевается, что функция ОБОРОТ отбирает обороты только при тех значениях
фильтров, которые заданы пользователем в форме как обычно. Просто вместо числа,
заранее подсчитанного пользователем вручную, подставлено указание, как подсчитать
это число.

   2004-10-28 01:37:10 (#252126)

[abilitycash] |dervish.acash| Количественный учет 006.009

:)) И тем не менее,...
всё-таки самовыражается. :) Вон, в графике \"Динамика оборотов\", я, честно говоря,
оттянулся по полной программе. :))

   2004-10-28 00:11:24 (#252081)

[abilitycash] |dervish.acash| Загрузка курсов валют 2 005.006

Возможно, что и недостаточно.
Но всё равно, это сможет разрешить закачку для многих пользователей. Так что
нужно делать. Имхо.

   2004-10-28 00:11:13 (#252080)

[abilitycash] |dervish.acash| Стандартные операции 010.013

А вот этого я пока...
...не планировал.

С одной стороны, это довольно непросто технически реализовать. С трудом себе
представляю, как именно пользователь должен будет ввести это динамическое значение.

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

Нет уверенности у меня.

   2004-10-28 00:10:58 (#252079)

[abilitycash] |dervish.acash| Количественный учет 007.008

Да, сейчас я это явно...
...не потяну. Отложим пока.

   2004-10-28 00:10:48 (#252078)

[abilitycash] |dervish.acash| Стандартные операции 008.011

Владимир, я надеюсь,...
..что вы видите как продолжается работа над программой. Я стараюсь и дальше её
развивать и учитывать те замечания, которые звучат в форуме.

И против ваших замечаний у меня нет никаких возражений. Дело только в том, что
я физически не могу сделать всё и сразу. По мере того, как я переключаюсь с одного
участка кода на другой я стараюсь учитывать всё, что говорилось про этот участок.

Так что шанс и надежда есть, всё только вопрос времени.

   2004-10-28 00:10:39 (#252077)

[abilitycash] |dervish.acash| Стандартные операции 009.012

Наверное я слишком часто...
...обижал операции перевода, что у вас сложилось такое отношение. :)

На самом деле я не буду вводить ограничения на тип операции. Посмотрите, в примере
использования шаблона операции я как раз и показал операцию перевода.

Так что хочу сказать, что операции перевода дискриминации в этом вопросе подвергаться
не будут.

   2004-10-28 00:10:21 (#252076)

[abilitycash] |dervish.acash| Ошибка и пожелания 001.002

Если позволите,...
я в том же порядке вам отвечу:

Ошибка. На самом деле ошибкой не является. Посмотрите верхний ряд чекбоксов.
Слева - \"Приходы\", справа - \"переводы на счета\". И в том и другом случае
имеются ввиду операции, увеличивающие остатки по выбранным счетам, по счетам,
по которым строится график. Я согласен, что тут проблема есть, но она в том,
что названия чекбоксов неудачные. Метки к чекбоксам переводов можно понимать
двояко. А как назвать, я, честно говоря, не знаю. Можете предложить другой вариант?
С удовольствием рассмотрю предложения. А, может быть, там вообще имеет смысл
переделать интерфейс? Я не знаю.

Второе. О сохранениях узлов списка. Пока вообще сохранение/восстановление в программе
сделано не очень хорошо. Это будет дорабатываться, я постараюсь реализовать один
общий для всех контролов подход. Дело будущего.

Третье. Об удалении значений классификаторов. Вначале я посчитал, что в таком
диалоге нет необходимости, раз реализовано перетаскивание в дереве. И только
потом, когда начал сам работать с программой, увидел, что упомянутого вами диалога
всё-таки не хватает. Но, к сожалению, я уже переключился на другие вещи в программе.
Так что я сам хочу сделать такой диалог, но делать его буду тогда, когда вернусь
к работе над закладкой классификаторов.

И последнее. О разделителях. Вы правы, это нужно сделать. В планах.

Спасибо за ваш интерес к программе!

   2004-10-28 00:09:57 (#252074)