создать новую тему раскрыть все
 
Хочу собрать здесь таковые - исходя из минимума неизбежно возникающих у предпринимателя структур.
1. Должен вводиться признак режима работы - "Предпринимательский".
2. В этом режиме:
2.1 Список видов операций сужается до одной строки - "Перевод"
2.2.1 На странице счетов кроме "Все счета" появляются ветки групповых счетов:
2.2.1.1 "Товарно валютные счета"
2.2.1.2 "Расчеты с поставщиками и подрядчиками"
2.2.1.3 "Расчеты с покупателями и заказчиками"
2.2.1.4 "Расчеты с прочими дебиторами и кредиторами"
2.2.2 На странице классификаторов появляется строка "Товары" и возникает страница "Товары"
2.3.1 При вводе каждой новой товарной позиции генерируются:
2.3.1.1 наименование счета - новая подстрока в 2.2.1.1. Генерируется тупо - добавлением к наим.товара префикса Скл. На этом счете будут копиться и с него расходоваться товары в натуральном исчислении
2.3.1.2 наименование и обозначение товарной валюты, тоже тупым добавлением префикса V-.
Я могу так и далее, но есть ли смысл?(Это вопрос к Дервишу)
 
Dervish: Итак, по порядку:
 
1. Нужные ветки групповых счетов можно создать и вручную. Зачем это нужно делать автоматически? Я, на самом деле, уже довольно много повидал различных баз данных пользователей и могу сказать, что каждый ведёт учёт так, как ему нравится, и все мои попытки подсказать, как было бы лучше учитывать оказываются тщётой. Поэтому лучшее, что можно сделать, это дать универсальный механизм, который можно использовать и так и эдак. И чем меньше в этом механизме будет сущностей, тем лучше, поскольку (известный факт!) Help почти никогда не читается.
 
2. Не нужно ограничивать виды операций только переводами, потому что, если это сделать, то следует дальше ввести ввести понятия "Дебет" и "Кредит", а вслед за ними потянутся другие... И в итоге мы получим совсем не то, что у нас было изначально. Кроме того, лично мне не нравится работать в двойной записи (хоть я и уважаю выбор других пользователей) и поэтому я хочу оставить возможность кассовой работы.
 
3. Аналогично легко создаются и классификатор "Товары" и добавляются префиксы к валютам. Это делается всего один раз, мне кажется, что нет особой нужды это автоматизировать.
 
Валерий, увы, но из-за того, что я работаю в С++, в итоге действительно получается довольно компактный и быстрый код (как пишут варёзники, программа "маленькая и шустрая"). Но оборотная сторона этой медали, что любая интерфейсная доработка программы занимает значительное время. Увы, я пока (пока копится код и пока ещё у меня нет универсального механизма для генерации user-interface) не могу быстро наращивать возможности программы. Not so
 
И вообще не очень понятно всем-ли предпринимателям это надо. А если не всем, то зачем городить огород?
 
Dervish: Лично мне больше нравится идея сделать для предпринимателей отдельную версию программы. На основе существующего кода, но специальную.
свернуть/развернуть ветвь кхе-кхе-кхе [Explorer 17/06/2004 17:42] # написать ответ
 
что то подсказывает мне, что это будет(?) не версия программы а просто другая программа...
свернуть/развернуть ветвь Минуточку, давайте разберемся... [В.Червонных 17/06/2004 20:31] # написать ответ
 
Естественно, все это сейчас можно (и нужно) делать вручную. Просто наличие этой минимальной автоматизации облегчило бы жизнь тем предпринимателям, которым AC понравилась, но товарных позиций, положим, несколько сотен.
Дело в том, что где-то мелькнуло обращение Дервиша к нам, пользователям, выдвигать предложения по интерфейсу. Для отбора на перспективу. Я вовсе не предлагаю все бросить и считать, что это - самое главное нынче. Есть вещи важнее.
Например, реализовать хранение остатков как-то иначе, не в самих операциях, выводить обороты по счетам при разных условиях фильтрации операций.
Предпринимателям это нужно, конечно, не всем, только тем, у кого много разных контрагентов и много товарных позиций, тем кто хочет не только фиксировать, за что заплачено, но и то, пришел ли уже товар, какую часть товара надо еще требовать и т.д.
Если же у кого-то есть только одна товарная позиция, один поставщик и один покупатель, тот легко обойдется приходно-расходными операциями по  денежным счетам. Но делать из этого тот вывод, что и вообще не стоит давать возможность предпринимателям отслеживать переводами все факты хозяйственной деятельности, было бы экстремизмом (это к Loki камушек в огород Well) Сергей, а как без двойной записи (переводов) зафиксировать, скажем, долг поставщика и факты его частичных поставок по предоплате? Да чтобы еще параллельно состояние склада изменялось? Я просто боюсь, что чего-то не понял и слишком усложняю...
свернуть/развернуть ветвь Надо добавить: [В.Червонных 18/06/2004 01:23] # написать ответ
 
Я же предложил, к тому же, дать возможность включить, а значит и выключить, когда он не нужен  данный режим. То есть, пока нужен пользователю предпринимательский режим, он им пользуется, захотелось писать небалансируемые приходы/расходы - режим отключаешь и работаешь без двойной записи. Я бы, наверное, не выходил из него, а кто-то входил бы редко, например для описания покупок в кредит.
свернуть/развернуть ветвь Каюсь:) [Loki 18/06/2004 19:45] # написать ответ
 
сейчас призадумался - в вашем примере действительно без двойной записи не обойтись. Только у меня возник вопрос: а как быть в случае нетоварных позиций (напр. услуги)? Если с поставщиком товара все ясно: кошелек - долг поставщика - склад - (...) - покупатель - кошелек, то например услиги транспортной компании, зарплата сотрудников и пр. как выражать в количественном выражении? или вести все в денежном выражении, но тогда без операций дохода/расхода не обойтись.
свернуть/развернуть ветвь Услуги и труд [В.Червонных 19/06/2004 01:11] # написать ответ
 
Чаще всего не требуется считать нерублевой валютой, так как не требуется, как правило, их учет в натуральных единицах. Хотя и бывает - человеко-час, если почасовая оплата. Можно задолжать за человеко-часы, причем вскоре это может быть станет очень актуальным, если введут минимальную плату за час работы. Будем открывать на каждого нанятого свой счет, со своей валютой (часто совпадающей с валютами других аналогичных счетов). Кстати говоря, ничего страшного, когда все ведется исключительно в денежном выражении, операции доход/расход не могут кратко заменить операцию Перевод. При нормальном учете всегда фигурирует ПАРА счетов, на одном расход денег, на другом приход в той же сумме, поскольку ВАЖНО не только СКОЛЬКО потрачено, но и НА ЧТО. Последнее, в отличие от обыденной жизни, определяется не наименованиями продуктов, а ЦЕЛЯМИ расхода. На оплату труда, на ликвидацию задолженности за товар, или же аванс на тот же товар. Ну как отличить одним взглядом расход на выплату транспортной компании некоей суммы, за что - за выполненную перевозку или за намечающуюся. Либо классификаторами, в которые надо еще залезть, либо переводом из кошелька на "правильный" счет. И пока, как я понимаю, остаток на счете - вещь более доступная, чем отфильтровывание по классификатору и расчет оборотов с его конкретным значением.
 
С самого начала подразумевалось, что Cash не предназначен для товарного учёта. Только для учёта денег. И я, конечно, понимаю, что в некоторых случаях это перекликается и, действительно, если товарная позиция всего одна (или несколько, но немного), то можно обойтись средствами Cash для их учёта. Но эта программа не годится для полноценного складского учёта, я прекрасно понимаю, что когда товарных позиций тысячи, их просто невозможно отслеживать в этой программе.
 
Увы, но мне совершенно незнаком товарный учёт, мне совсем не приходится работать со складом. А раз я сам со складом не работаю, то у меня возникают большие сомнения, что у меня получится сделать что-либо путное. Потому я пока и отказываюсь от таких доработок программы.
 
Кроме того, доработки, связанные с введением префиксов (например в валютах - см.выше), это настолько специфическая вещь, для которой я не могу подобрать иного определения кроме слова "заплатка". А любая заплатка (а) не решает в полном объёме проблему и (б) уродует исходный материал.
 
Программиста Вашего уровня смело следует приравнивать к математику. Математик обычно не интересуется, что именно стоит за рассматриваемыми им объектами. Лобачевский взял неэвклидовы аксиомы - смысл геометрии придали много позже. Не хотите занимались товарным учетом - и не надо! Если нашлись пользователи, ухитряющиеся интерпретировать товар как равноправную другим валюту и использовать УЖЕ сделанные операции перевода - то все, что требуется, по возможности (!!), пойти навстречу пожеланиям этих пользователей. Смотришь, дойдет дело и до учета сначала десятков валют, потом и сотен и тысяч... Вполне возможно, валютный подход к учету товаров обладает мировой новизной,поэтому любой опыт в товарном учете может оказаться для программиста даже вредным.
 
И всё-таки префиксы мне жутко не нравятся, не профессионально как-то. Лучше думать, как это сделать иначе, по-другому.
 
оставляем на будущее, а как именно будет сделана реализация - будем думать. Еще пока таких пользователей нет, для которых именно эта вещь была очень актуальной To wink
 
и в пр-пе я сейчас вижу закономерный вопрос - "почему нет"
 
ИМХО - если не лениво и есть возможность - неполохо было бы оставить "заглушки" на будущее и в схеме данных (формате базы) и в и-фейсе
 
не нужны, в отличии от первой версии, вторая позволяет делать существенные доработки и по формату данных и по интерфейсу.
 
я про jump со счетов в операции!
 
можно настраиваемый,
Очень бы хотелось уже услышать что в 193 билде уже появится такая фича.