Здравствуйте, уважаемые форумчане.

Мне поставлено следующее задание:
Необходимо автоматизировать ведение лицевых счетов по программе "Жилье в рассрочку".
Суть задачи: к заемщиком заключается договор аренды с последующим выкупом. Организация приобретает жилье. Заемщик выплачивает платежи: выкупные за жилье, проценты за обслуживание займа.
Платежи следующие:
20% стоимости жилья - начальный взнос. Относится на счет 80.10.3, после выплаты заемщиком всей суммы ложится на 62.02, для последующей покупки жилья у организации.
от 75% стоимости жилья рассчитывается 20% годовых - арендные платежи за пользование займом. Выплачивается равными долями, ежемесячно. Относится на счет 76, а затем на доход организации.
от 75% стоимости жилья 0.5 процента, но не более 1000 рублей - комиссионные платежи. Выплачивается ежемесячно. Относится на счет 80, но затем на доход не переводится.

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

сколько?

(0) ну вот же товарищ торгует, можете у него купить v8: Если вам заказали проект, создание продукта, который можно будет продавать

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

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

Идея темы - открытая дискуссия, в которой участники могут высказать свое видение предмета разработки.

Сейчас там есть регистр накопления следующего вида:

Измерения : ЛицевойСчет
Ресурсы: ВыкупнойПлатеж, ЧленскийПлатеж, ЦелевойПлатеж, Пеня, Штраф, Комиссия.

Понятно, что в новой программе эти ресурсы отличаются.

При этом, в регистре фиксируются взаиморасчеты по начислению и гашению. А в целом суммы остатков к выплате при выводе карточки - каждый раз пересчитываются.

И мне показалось, что будет здорово сделать регистр, в котором будет такая структура:

Измерения: ЛицевойСчет, ВидПлатежа
Ресурсы: Сумма

Таким образом, мы сможем отражать в регистре информацию о взаиморасчетах универсально, и преемственно.

Теперь думаю: сделать ВидПлатежа перечислением, и описывать все алгоритмы, в коде, или...

... сделать справочник для видов платежей, и регистр для отражения правил начисления, гашения, и отражения в учете этих платежей.

Но последнее мой слабый мозг вообразить пока не может...

(0)с нуля писать будешь или нашлёпка на что либо?

(6) На базе БП 1.6, сильно доработанная под потребности кредитной организации. Написана плохо, но, как говорится, пока не сделал лучше - не ругай чужое.

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

(7)если хочешь нормальную подсистему нужно где-то 80-120 часов минимум

(5) правильно, сделай как можно более универсально, чтобы сложней было объяснить конечному пользователю и, следовательно, сдать проект. Но когда пользователь во все врубится, тогда ты нафиг уже никому не нужен будешь, платить за дополнения и сопровождение никто тебе станет. Прекрасная перспектива.

Платить готовы в полном объеме, но нужно соизмерять затраты с доходом.

(10) Объяснять я буду студенты программисту, которого и должен туда найти на фикси.

студенту*

То есть, надо что-то среднее между идеалом, и никчемностью.

(4) Мне одному кажется, что идея темы не дискуссия, а получение на халяву идей разработки? :))
Почему бы не нанять профессионалов за деньги?

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

(16) Да я собсно не против сабжа и попытки получить некоторое количество идей.
Просто мне не верится, что народ сейчас ломанется в огонь таскать каштаны :))

(8)+ и из этого времени на проектирование 30-50 часов это в лучшем случае

(17) Между прочим, я не написал "Вот такая задача, чо мне с ней делать?" Я написал "Думаю сделать так-то. Что скажете?". Как минимум можно привести пример из своей практики "А я видел вот так", или пофантазировать "А я бы сделал вот так".
Тем более, если человек на хочет участвовать в дискуссии, его не заставляют.
Давайте не будем засорять, мне интересно не это.

(19) "Между прочим, я не написал "Вот такая задача, чо мне с ней делать?" Я написал "Думаю сделать так-то. Что скажете?""

перечитай (0)

(18) Дело не в часах, и не в сложности. Я изобретаю велосипед, и не хочу сделать ему квадратные колеса. Кто ни будь работал в банковском, кредитном секторе? Кто ни будь, не дай бог автоматизировал это одинэсом?

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

(20) Обратите внимание на (5), (7)

(22) Персонально вам я разрешаю не вкладывать свое драгоценное время в мои деньги, и прошу закрыть данное направление обсуждения.

(23) смысла нет

(22)бизнесс идея ну это никак не готовое решение, а тут автор даже про бизнесс идею не говорит

(26) если говорить подробнее, то там уже есть реализованная программа, которая до 2009 года все считала. Потом поменялся закон немножко, и она перестала считать. Теперь поменялись проводки, виды платежей, и она даже не подходит, если её и наладить.
То есть подходит, но только для старых. А нужно еще и вести новые, и возможно будут изменения. Таким образом передо мной встает вопрос о хранении данных. Пришел в к выводу, что нужно переделать регистр. Потом подумал, что вид платежа может само определять суммы и алгоритмы расчета... а дальше мысль не идет.
Тут еще какой вопрос: а как бы это выглядело на регистрах расчета? Я с ними не знаком абсолютно, и не знаю, как они ведут себя. 1С же обещает, что на регистрах расчета можно рассчитывать квартплату. Почему бы ему не рассчитывать ипотеку?

(27)у регистров расчета самое важное это перерасчет, он тебе нужен?

(28) Нет, это не нужно.

еще что касается хранения информации: карточка лицевого счета выглядит примерно так (сокращено):

Внесли нач. взнос 20 000
- оплачено выкупных взносов 20 000
- осталось оплатить выкупных взносов 80 000
Начислили ежемесячные платежи
- начислено арендных платежей 2 000
- оплачено арендных платежей 0
- осталось оплатить арендных платежей 80 000
- начислено выкупных взносов 2 000
- оплачено выкупных взносов 0
- осталось оплатить выкупных взносов 80 000
- начислено комиссии 1 000
- оплачено комиссии 0

Пришел оплатить 5 000
- оплачено арендных платежей 2 000
- осталось оплатить арендных платежей 78 000
- оплачено выкупных взносов 2 000
- осталось оплатить выкупных взносов 78 000
- оплачено комиссии 1 000

Я примерно думаю о следующем: в этом регистре совмещаются понятия текущего взаиморасчета по начислениям, и общего взаиморасчета по сделке.

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

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

(16) А "создать дискуссию для обмена деньгами" ты не хочешь? :-))

Итак...

Был найден продукт "Учет в микрофинансовых организациях". Стало быть, тему немного исследовали. Там достаточно универсальные механизмы, нужно будет взять на заметку.

А тем временем, были проведены следующие работы:
В основе работы лежит классификация платежей/взносов через справочник, пока через предопределенные элементы, но кажется, можно будет и без этого.
Для каждого вида взносов можно создать график начисления.
- регстр сведений "График начисления", в котором есть измерения: Дата начисления, Лицевой счет, Вид взноса, и ресурсы: Сумма, Номер графика (На случай изменения графика по соглашению сторон)
Данные служат для расчета начислений за период, и попадают в регистр накопления "Взносы", в котором есть измерения: Лицевой счет, Вид платежа, и ресуры: "Сумма", "Всего".
В первом ресурсе рисуем приход/расход текущих платежей, во втором ресурсе рисуем напогашенную задолженность, и плавно её гасим.

Критика?

Сначала делал через один ресурс, и делал в справочнике две записи: "Выкуп", "ВыкупОстаток".
Делалось из-за того, что есть комиссионные платежи, которые остатка вроде не имеют, т.к. сумма может меняться. Но фактически вроде как и есть остаток этой суммы. Но тогда, при смене ставки комиссии, придется всем друзьям пересчитывать графики. С другой стороны, в старых данных ставка другая, и база начисления другая, и никто пока её не пересчитывал. Жилье же не автокредит.

Возник интересный вопрос:

Ведение лицевого счета состоит из двух действий: начисление, гашение. Лицевой счет ведется в разрезе трех видов платежей. При этом гашение выполняется в порядке очередности видов: Вид1, Вид2, Вид3.

Например, начислено Вид1 = 5000, Вид2 = 4300, Вид3 = 7000.
А человек принес 13000. Тогда гасится Вид1 = 5000, Вид2 = 4300, Вид3 = 3700.

Если происходит переплата, то соответственно в таком же порядке происходит гашение будущей датой.

И проблема вот в чем: для соблюдения полноты и очередности гашения , хранение данных производится в регистре накопления (31). И данных ОстаткиИОбороты этого регистра видно, какие месяцы недоплачены, или какие месяцы переплачены.

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

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

Что подскажут гуру?