Форум » Коммерческие программы » Идея для повышения ценности программы » Ответить
Идея для повышения ценности программы
Cablemaster01: Почти у всех клиентов есть договора, которые оформляются у Вас в программе в виде Документа (счета) и он же договор расходов и услуг. Договор характеризуется тем, что у него есть дата начала и дата закрытия. Дата Докумерта( счета) в программе есть. А вот даты закрытия нет. Дата закрытия договора может быть фиксирована - вводим ручками А может быть от даты поступления денег на счет - вводим при оформлении плат поруч или кассового ордера. Как можно было бы использовать дату завершения договора? + ну можно было бы сделать репорт о завершающихся Документах, например, делаем за месяц и неделю и видим какие документы надо закрыть... + в перспективе создание автоматического оповещения а ХХХ дней до конца по e-mail ( например настраиваем на почтовые адреса сообщение о том, что договор завершается) Есть договора, где ежемесячно надо выставлять счет на услуги Все данные для этих услуг есть, банковские реквизиты, e-mail и было бы здорово, чтобы система сама присылал счет клиенту ежемесячно на такие услуги, то есть не надо самому каждый раз вспоминать ежемесячно о том, что надо выставить счет, а программа выставляет счет на оплату услуги...
Ответов - 8
memo4x4: Как таковых списка договоров нет, это наверно в общем случае невозможно формализовать, любое решение по ведению договоров будет частным. Сейчас в программе есть 2 варианта подготовки доворов (как отчетов по шаблонам пользователей в MS Word / OO Writer) - на основании документа склада и на основании карточки контрагента.
Cablemaster01: Распечтать по шаблону не вопрос договор и я это уже делаю, за что Вам спасибо - тут все понятно. И кстати, поэтому я и выбрал Вашу программу, что можно шаблоны менять и подставлять. Правда я Вам писал, что хорошо бы отдельно выделить три поля отдельных - дата, месяц прописью и год в шаблоне, для простановки в поле накладной ТОРГ-12 в соответсвующих полях в самом конце. Задача по договорам достаточно неплохо формулизуется для процентов 90% договоров - строительные посложнее конечно. Очень много ИП и компаний, особенно тех, кто предоставляет услуги работает по договорам и для них этого головная боль. Мне, если честно и без этого жить пока можно, но если количество договоров будет увличиваться, то функция контроля и выписки счетов по периодам станет актуальной, так как в голове удержать более 7-ми договоров проблематично. Для того, чтобы решить задачу контроля договора, можно было бы добавить два поля в таблицу Документов (счетов) - дату завершения Документа + Дату оповещения + 2 текстовых поле сообщения Как я писал дата завершания проставляем сами, либо по оплате, либо можно было бы указать продолжительность Документа и дата сама вычисляется либо от даты оплаты, либо от даты создания документа Дата оповещения - ставим контрольную дату сообщения... Исходя из этих полей уже можно строить сервисы Ну например, можно сделать хотя бы отчет - указываем период и в этот период попадают оповещения и даты завершения договоров и сразу видим, что нам нужно сделать Контрагент, номер Документа, Дата оповещения, сообщение, Дата завершения, оповещение по дате завершения Далее можно усложнять этот сервис, когда система выводит сообщения при входе в систему, что сегодня Вам дескать надо не забыть сделать для контрагента по такому то документу то-то Можно еще усложнить - система пишет нам по мылу, что мы должны сделать... Периодические договоры посложнее конечно, но тоже формализуются через этапы ( этап может быть периодом) Но тут надо думать, как у Вас реализовать софтом
memo4x4: Я все прочитал и улышал ... ;)
Cablemaster01: Добавляем всего одно поле в Документ(счет) номер договора Если у документа один и тот же номер, то он относится к одному договору. Уже можно иметь различные сервисы только из этого поля в репортах, ну например увидеть сколько заплатил контрагент по данному договору. Но это только начало :-) Создаем таблицу договоров, где указываем общую сумму договора, начала договора, конец договора ( или продолжительность ), контрагента, СТАРТ ( 1-ый пероиод или этап), ПОВТОРЯЕМОСТЬ ( по продолжительности или товарам/услугам), КОНЕЦ ( последний период иди этап) СТАРТ договора - дата начала и дата конца старта, работы и товары, которые входят в старт, так как СТАРТ может отличаться от последующих (отличаться может еще и потому, что 1-ый этап может начаться не с 1-ого числа месяца). ПОВТОРЯЕМОСТЬ - то есть те услуги или товары, которые повторяются по договору, указываем работы и товары, старт повторяемости и конец повторяемости или указывам продолжительность периода (тут еще можно подумать как лучше сделать) и количество периодов. Если количество периодов указать 0, то они активизируются кнопкой принудительно, то есть мы на момент заключения сделки реально не знаем сколько будет повторяемостей - такое бывает. Можно продолжительность указать 0, то есть мы по контратку должны закупить 6 контейнеров сахара, но закупать будем сахар, тогда когда он будет распродан - то есть время периода не определено. Например, клиент постоянно покупает 1 контейнер сахара, возникла потребность - нажал на кнопку договора - сформировал Документ на приход по договору... Далее указываем КОНЕЦ договора - аналогия со СТАРТОМ, так как конец может отличаться от СТАРТА и от пероида. Ясный пень, что в простейших случаях СТАРТ и КОНЕЦ могут совпадать с ПОВТОРЯЕМОСТЬ, когда не надо выделять СТАРТ и КОНЕЦ, например, заключаем договор с 1-ого числа на сервис и он каждый месяц одинаково закрывается. Теперь самое вкусное - нажимаем кнопку и система генерирует нам Документы (счета) причем она уже знает начало и завершение Документа(счета) Хорошо бы и не нажимать кнопку, а указать генерацию автоматическую документа согласно договору, то есть система сама создает документ за Х дней, если указать поле и присылает еще и e-mail счет контрагенту... Ну и т.д. - накручивать можно много чего полезного и внусного для пользователей... Фактически мы имеем еще одну таблицу - Договора и это некого рода ПЛАН А факт, это наши реальные Документы (Счета), которые мы генерируем на основе плана, а потом еще ведем и которые могут ведь и измениться в силу разных причин У строителей вообще головная боль закрыть ПЛАН - ФАКТОМ В таблице Договора сразу будет видно сколько уже по договору проплачено % по договору, как план от факт отличается, что мы должны по договору или что нам должны... Вот так просто и со вкусом можно решить задачу практически любой сложности с договорами
rinat: Наконец-то появился товарищ по процессу учета договоров Вы как-то сложновато предлагаете решать этот вопрос, но нормальному же надо, при заключении договора,завести приход с количеством периодов обслуживания, и в расходе списывать... вы же просто генерируете документы без складского учета.
Cablemaster01: Мое предложение состоит из нескольких этапов Самое простое добавить хотя бы два поля в Документы - номер договора и дата закрытия документа. Теперь о сложном. Договора бывают разные - есть договора по этапам, где этапы разные Есть договора периодические А есть договора, отличающимися началом и концом + в середине периодические. Поэтому при формализации и описании я учел все эти моменты Я не говорю о том, чтобы не гененировать документы без складского учета - их обязательно нужно генерировать - это отчетность. Однако предлагаю генерировать их на основе Талицы договоров, то есть мы вводим Договор и там у нас есть документы - фактически некоторые план, а потом на его основе генерирует документ для складского учета - это уже получается факт. Причем генерация может быть, как по кнопке, так и автоматом, если мы настроим... Что очень важно именно для договоров у которых, что-то есть в периоде и постоянно повторяется. Если использовать данный механизм, то фактически решается все мыслимые задачи по договорам, включая, кстати и строительные, где масса нюансов, связанных с тем, что есть план, есть факт. И еще, то, что я предлагаю не затрагивает уже написанный функционал, то есть в принципе все можно реализовать степ бай степ разработчику. Если разработчик MEMO это релизаует, то продавать его программу станет на порядок проще, так как мало где реализован хороший механизм постановки задачи автоматизации договоров - проблема с постановщиками однако.
rinat: судя по тому, что разработчик не ответил, это не его профиль... скорее всего для фирм работающих с договорами программа слишком дешевая, и нет рекламы. А работать с вашим предложением, без возможности реализовать наработки... нема дурных.
memo4x4: rinat пишет: А работать с вашим предложением, без возможности реализовать наработки... нема дурных. Я бы разделили вопрос и ответы по нему на два: - мы с интересом читаем всю инфрмацию в форуме и если Вы посмотрите перписку, то после того как некоторая идея, становится формализованной, обретает некоторые конкретные очертания - то она как правило реализуется. И в первую очередь здесь важны не лозунги "Как хорошо будет продаваться Ваша программа, когда Вы сделаете, то что мне нужно", а действительно продуманность и грамотность постановки задачи, в контексте существующих схем учета для программах о которых Вы спрашиваете. - возможности для разработки, о которых Вы говорите - они предоставляются Вами (т.е. пользователями программ) и пока действительно, как Вы говорите "нема дурных" которым это действительно нужно для работы - это так и останется незакрытой темой в форуме. По моему все логично и правильно, хотя если кто-то считает свои идеи бесприкословно великолепными - это может показаться обидным. Если есть возражения, замечания, а еще лучше - конкретные предложения - пожалуйста пишите ... :)
полная версия страницы