logo
logo

Форум Предложение

создать новую тему раскрыть все
Предложение Hoblin 04/03/2002 15:12 #написать ответ
Добрый день.
Предложение, собственно, такое :
При трансфере средств с одного счёта на другой, неплохо-бы было-бы иметь возможность задать транзакционные издержки. Пример : покупка наличных долларов - оплата проводится по формуле курс + 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.