Добрый день.
Предложение, собственно, такое :
При трансфере средств с одного счёта на другой, неплохо-бы было-бы иметь возможность задать транзакционные издержки. Пример : покупка наличных долларов - оплата проводится по формуле курс + 1% от курса + 1RUR
Dervish: Наверное, неплохо. А зачем?
Чем это может помочь?
RE: Предложение
catkin
04/03/2002 23:53
#
В эту же область,
у нас при переводе с банковского счёта куда либо берут х деньгов, было бы неплохо, если бы для данного счёта можно было бы установить правило, что при переводе или расходе делать дополнительную операцию - услуги банка = -x$
Dervish: А у всех банков тарифы одинаковые? Насколько я знаю, нет. Значит, надо сделать целую подсистему для ввода банковских тарифов в программу? Вы представляете объём этой задачи?
RE: RE: Предложение
Женя
05/03/2002 13:10
#
На мой взгляд, это задача для будущего (далекого). SOHOвцы наверняка заинтересованы в возможности проведения проводок по нескольким счетам в рамках одной операции. Конечно, делать привязку к комиссиям и т.д. - задача очень сложная, и врядли сейчас можно сказать, как именно следует реализовать такого рода операцию в виде стандартной (такой же, как сейчас Приход, Расход и Перевод).
Промежуточный вариант решения (и тоже на будущее) - дать возможность в одной операции сделать неограниченное число полупроводок. Такая операция называется НЕСТАНДАРТНАЯ. В каждой строчке, число которых неограничено, можно указать счет и сумму. По всей операции указывается, как обычно, дата и реквизиты (проект, статья и т.д.).
Можно продумать также возможность создания шаблонов операций, в которой будут прописаны реквизиты и счета в строках. Останется только наполнять операцию цифрами и датами.
К сож, не знаю структуру базы и строение обьектов, посему сорри, если это совсем не вписываюсь в своих домыслах...
Dervish: Верно говорите: далёкое будущее... Увы...
SOHOвцы заинтересованы
Экс-Плорер
06/03/2002 12:05
#
Если для операции будет реализован один уровень детализации (одно вложение) - этого будет вполне достаточно для того, чтобы учесть и комиссию при переводе со счета на счет и пр. и пр. и черта в ступе. И никаких НЕСТАНДАРТНЫХ операций, пусть это будет стандартной опцией для любой операции.
О шаблонах операций (кстати как и о настраиваемых атрибутах операций)- да, все верно и ЗАМАНЧИВО - но, вероятно, все-ж "далекое будущее".
Dervish: Всё верно, но, если честно, я пока даже представить себе не могу логику, как должна работать программа с вложенными операциями.
CFVJT GHJCNJT/// Тьфу черт! Самое простое...
ЭхмПлорер
06/03/2002 15:49
#
Представим, что в таблице "операции" появляется дополнительное поле "ParentRecordID" - это ЕДИНСТВЕННОЕ изменение в структуре данных. Операции можно вводить двумя путями - орально и ваг... Тьфу... В Ленточной форме и в Диалоговой форме. Введя операцию со всеми атрибутами в диалоговой (как сейчас) мы можем вызвать ленточную (или это может быть ленточная субформа), в которой будет всего два (например)поля "наименование" и "цена". все остальные поля таблицы заполняются данными из диалоговой - вызывающей формы... Из её-ж берется и "ParentRecordID"
Все.
В списке операций присутствуют только записи у которых "ParentRecordID" = NULL
Для них и вызывается "диалоговая форма" из нее ток можно вызвать ленточную. Токим образом вложения ограничиваются одним уровнем. Можгно добавить запись в уровень, но нельзя добавить уровень к записи у которой есть "ParentRecordID" (<> NULL)
Если извращаться и придираться - то общие данные в подчиненную запись вносятся из родительской, а суммирующие (Сумма расхода) пересчитываются из подчиненных записей (цена или стоимость) в родительскую
Dervish: Не так всё просто. Если бы дело оканчивалось только вводом операции и её хранением. А графики (и в будущем отчёты)? Да и простой трюк с ParentID тоже, на самом деле не очень проходит... Так уж устроен сейчас Cash.