уважение к долгам

уважение к долгам Ed 06/05/2003 13:53 #

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

2 Операция возникновения - погашения деньгами имеет двойной характер - с одной стороны увеличиваются (уменьшаются) средства, а с другой стороны возникает (погашается) обязательство, что вынуждает делать 2 идентичные операции

Сейчас для учета долга заводится счет. Например, мы взяли в долг. При расчетах деньгами нужно делать 2 операции – регистрировать на счете долга и приходовать на счет наличных. То же самое при погашении – параллельно операция расхода и закрытия задолженности. И при погашении сейчас рассчитывается только общий остаток долга, а было бы неплохо ввести понятие «погашенной/не погашенной задолженности». В том числе частично. Особенно это было бы полезно для пользователей, которые хотят функцию начисления процентов, когда по одному агенту числятся долги с разными ставками

Dervish: С констатирующей частью согласен безоговорочно.

продолжение :-) Ed 06/05/2003 13:54 #

Суть предложения приблизительно в следующем. Ввести тип счета «Отношения долга» и по этим счетам регистрировать операции возникновения-погашения с параметром «формировать приход» или «формировать расход». Если выбирается операция погашения задолженности, то (на соседней вкладке, например) отбираются не закрытые операции возникновения в соответствии с параметрами погашения (агент, статья, проект) и отмечаются нужные, которые становятся закрытыми (полностью или частично). При этом, если суммы не хватает для полного закрытия всех выбранных программ должна вычислить суму частичного закрытия автоматически и предложить пользователю выбрать какой долг останется таким «неполноценным». В результате получим 1 операцию вместо 2, не нужно будет заводить отдельные счета для каждого агента – достаточно будет их указывать в соответствующем поле, можно будет контролировать каждый конкретный долг или неоплаченный счет.

Извините за многословность и спасибо за программу – это лучшее, что довелось попробовать.

Dervish: А теперь, собственно, комментарий к вашему предложению:

Лично я с очень большим уважением отношусь к долгам, поскольку в моей рабочей базе данных их довольно большое количество. Однако, мне представляется, что полноценная реализация учёта долгов есть очень и очень непростая задача. Самая большая сложность, имхо, состоит не в том, чтобы правильно считались проценты и выдавались все необходимые формы и результаты, а в простоте работы с программой и, главное, интуитивной понятности того, что же именно делается программой. Я руководствуюсь следующим подходом: чем меньше сущностей, тем проще с ней работать. Вы же предлагаете (если я правильно понял) ввести следующие понятия:

1. Тип счета «Отношения долга»
2. Операции возникновения-погашения с параметром «формировать приход/расход»
3. Специальные принципы и алгоритмы для выполнения этих операций.

Боюсь, что это будет очень сложно. Тем более, для неподготовленного пользователя.

Мне кажется, что с учётом долгов в первой версии связаны вот какие проблемы: (а) ведение отдельных счетов для каждого из должников/кредиторов и (б) необходимость двух операций для любого действия по долгам. Так, может быть, не мудрствуя лукаво, просто автоматизировать эти сложности? Тогда от неподготовленного пользователя можно будет просто спрятать счета, которые программа будет создавать для учёта долгов, а подготовленный сможет не только посмотреть сами счета и операции по ним, но и исправить и вручную откорректировать данные по ним, если в этом возникнет необходимость. А в настройках просто добавить опцию, которая будет управлять доступом к счетам долгов "напрямую".

Как вам такое предложение?

Отношение к долгам Дёма 06/05/2003 20:04 #

Мне тоже приходится делать по две операции. Было бы неплохо еще при переводе указывать контрагента.

Dervish: А зачем вам нужен контрагент при переводе?

Контрагент при переводе Макаров 07/05/2003 08:48 #

Контрагент при переводе нужен - надо знать чей долг отдан или от кого получен

Dervish: Подразумевалось, что вместо указания контрагента для каждого долга будет создаваться отдельный счёт.

Впрочем, если вы считаете, что вам нужен контрагент, я не буду возражать: во второй версии вы сможете (если захотите) использовать агентов в операциях перевода.

контрагенты Ed 07/05/2003 13:54 #

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

Dervish: Да, во второй версии будет группировка счетов. Только "родительские" счета, то есть те, которые содержат подсчета будут отличаться от обычных счетов. Для родительских счетов не будет задаваться валюта и по ним нельзя будет совершать операции, зато их можно будет использовать при выборках и генерации отчётов.

предложение Ed 07/05/2003 14:20 #

Вы совершенно точно определили проблему (пункты а и б). Причем с контрагентами не такая уж и большая, если будет древовидная структура счетов, что вы, как я понял из обсуждений и планов, собирались сделать.
А предложение нормальное. Одно "но". Не всякая операция с долгами приводит в движению денег. И тогда надо думать, как при выполнении стандартной операции дохода/расхода этот самый доход/расход не отражать на денежных счетах. Через выполнено-не выполнено? Тоже не совсем удобно - опция, как мне кажется, для другого предназначена

Dervish: Мне всё же кажется, что для этой цели можно (и нужно) использовать признак "выполнено-не выполнено". В самом деле, я частенько ввожу в базу невыполненные операции на этапе планирования платежа. Получается довольно удобно: с одной стороны строчка постоянно маячит в списке не давая забыть о предстоящем платеже, с другой стороны невыполненная операция тут же отражается на графике остатков (в виде красного пунктира) и показывает, что будет происходить со счётом после её выполнения.

планирование платежей Ed 15/05/2003 21:34 #

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

Dervish: Да, вот тут я, похоже, просто напутал. В общем, если бы я учитывал долг, который возник, пусть даже и без движения денег, я всё равно (раз он уже возник) сделал бы операцию прихода на один из долговых счетов. Причём, реальную операцию, выполненную. Долг есть и он показывается (и отмечается) во всех графиках и отчётах. Но такой подход годится только для долгов, которые на крупную сумму.

А вот для мелких, текущих задолженностей, которые возникают от месяца к месяцу я делаю просто повторяющуюся операцию расхода на эту сумму и она у меня будет показана на графике остатков в виде красной пунктирной линии до тех пор, пока я не выполню платёж, закрывающий задолженность и не отмечу операцию как "Выполнено".

Мне кажется, что надо различать действительно долги, которые имеют разовый характер и текущие задолженности, которые возникают от месяца к месяцу.

не будем усложнять Ed 20/05/2003 21:45 #

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

Dervish: Спасибо.

Обобщая долги (Теория отношений хранения ) Explorer 15/05/2003 22:08 #

http://akop.ru/personal/1233?PARENT_RUBR=akop_art_it

Dervish: Спасибо. Похоже, пора ставить сайт http://akop.ru в букмарки. Интересный материал.

Рад, что удалось посодействовать Explorer 16/05/2003 23:40 #

вообще в сети очень богатый материал по этим темам. Как правило для того, чтобы им продуктивно пользоваться необходимо профессиональное знание предмета. Это довольно сложно и в принципе программисту (имеется в виду разработчику) незачем да и пожалуй - это было-бы явно завышенное требование.
Хотя БЕЗУСЛОВНО глобокое понимание и признание приоритетности или по крайней мере паритетности прикладной предметной области - залог успеха программного продукта (один из краеугольных камней)

да... И никто, никогда не раскрывает НоуХау и не отдает ключи от квартиры, где деньги лежат...

Dervish: Да, согласен: весьма любопытные ссылки.

Форум уважение к долгам