создать новую тему раскрыть все
свернуть/развернуть ветвь Список операций [Игорь 06/03/2002 08:08] # написать ответ
 
Может быть, имеет смысл рассмотреть возможность добавления подопераций в рамках трех существующих - приход, расход и перевод, т.е. чтобы можно было бы, например, в состав операций "Приход" ввести подоперации "Получение зарплаты", "Подарки" и т.д. Причем, хотя-бы одного уровня вложенности ... думаю, что это, наверное, не сложно реализовать ...
 
Dervish: Не так уж и просто. Возникает целый ряд логических вопросов, на которые лично я пока ответа не знаю. Например, надо ли требовать, чтоб все дочерние операции принадлежали одной статье? Как в графиках обрабатывать суммы родительской и дочерней операции? Должна ли совпадать сумма вложенных операций с величиной родительской? Если нет, куда девать разницу?
 
Сейчас тип операции можно определить с помощью СТАТЬИ, ПРОЕКТА, Примечания. Я использую, к примеру, ПРОЕКТ.
 
В будущих версиях пользователю будет предоставлена возможность создать необходимые атрибуты операций. Тогда Вы сможете описать каждую операцию с необходимой Вам степенью детализации.
 
Dervish: В общем, да... Очень хотелось бы...
свернуть/развернуть ветвь Хм- Насчет будущих версий... [Экс-Плорер 06/03/2002 11:55] # написать ответ
 
А? Сергей...
Будет предоставлена пользователю возможность?
 
PS Well)
 
Вроде как очень уж заморочисто это...
Посидел я пару вечерков над реализацией идеи определения атрибутов операций - и подумал... "А вот интересно - кому либо кроме меня это может понадобиться?"
 
А вот насчет одного уровня вложености - это как раз - "товар/количество/цена"
 
Dervish: Мне хочется предоставить... Другой вопрос, сколько на это уйдёт сил и времени... Фактор времени меня, честно говоря, пугает...
 
А насчёт разделения "товар/количество/цена", скажите, пожалуйста, как это всё разместить на диалоге редактирования операции?
 
Урааа! Наконец-то Эксплорер заговорил человеческим голосом, а не Active-Xом!!! ))))
 
Достаточно одного уровня.
 
Dervish: Эксплорера зовут Иваном.
 
Иван, ничего что я военный секрет выдал? Well)
 
"Товар/количество/цена" -  это три свойства одного уровня вложения для операции
 
разместить можно так:
У сингл форм "операция" есть сабформа "записи по операции" как континиос форм.
 
В ей-то все и чепятать.
 
Отмечу, что Родительская операция и вложеные в не записи о расходах по операции - суть одна таблица, один массив данных - так проще. (если есть желание напрячся и извратиться с изменением структуры данных - ап то ю)
 
просто для вложеных записей поля атрибутов заполняются "по умолчанию" данными родительской записи "агены/проекты/статьи"
данные самой вложенной записи "наименование/цена/количество/стоимость" - содержатся в тех же полях что в родительской записи "примечание/сумма расхода" в принципе - достаточно "наименование/стоимость", без "цены/количества".
 
На форме добавить кнопку - "детализировать операцию" сделать форму двустраничной и вуаля - на второй странице - списком - детали операции.
 
Ну как?
свернуть/развернуть ветвь Не нравится мне что-то... [Женя 06/03/2002 14:34] # написать ответ
 
Я видел себе по-другому:
1. Создание атрибутов операции.
Для операции определяются атрибуты. Пример: стандартные Агент, Статья, Проект, Примечание и по желанию сами создайте Цена за шт, Кол-во, НДС.
2. Для счета (!!!) определяются атрибуты операций, которые пользователь желает видеть в окне.
Пример: по счету 1 такому-то Вы желаете видеть только Примечание, Цена за шт, Кол-во, по счету 2 - Примечание, Статья
3. При выборе операции часть статей заполняется автоматически в зависимости от подвида операции (см. выше переписку), а остальные атрибуты просто выписаны столбиком один под другим. Вариант - можно выводить только стандартные, и сделать кнопку - Дополнительно, чтобы "выпали" остальные атрибуты для заполнения.
 
Вроде бы все.
свернуть/развернуть ветвь Я тоже так видел [}{е}{плорер 06/03/2002 14:57] # написать ответ
 
Но "помацав" тему ручками - поостыл...
"Наворот" получается громоздкий и тяжеловато это все. слишком (ИМХО-хо-хо-хо) большой крен в сторону профессиональных приложений.
 
Сдается мне что вроде как похоже на то что вероятно по моему скромному рассуждению быть может проСче боит реализовать тем макаром что я запостил ранее.
 
Хотя коечно - стебово былоб
 
Можно упростить, если предложить кроме стандартных атрибутов фиксированное кол-во дополнительных атрибутов (к примеру, 3 шт) с возможностью либо дать им навзание, либо (если сложно) дать выбор из списка 10-15 атрибутов (собрать с народа, какие хотят).
 
А сложностей я что-то больших не вижу! Подскажите, пожалуйста!
 
Нужно еще и определять формат выбираемого юзером поля. Прич если определенный формат выбран для хотяб одного поля в таблице - то есссесьно он таким будет для усех записссей хоч-нехоч.
Можно ток Хайдить/Анхайдить поле и усе.
 
Вот и прикинь - типа три поля запасных - одно Мемо одно Дата и одно Намба...
Ну и чо - богатый выбор? А если надо два поля Намба и одно даты - типа - извини подвинься, или пиши кода три страницы - чоп динамически изменять формат (или на форме делать 10 скрытых полей ввода с разными форматами тогда кода боит пять страниц) про ввод некорретных данных - вощ молчу (Data Type Mismatch)
 
Все - текст! Это Вы, батенька, хватили лишнего. Атрибут нужен для построения аналитики, CASHум не используется.
Так что и тип поля сделайте сразу
НИХТ! ой, шо я морозю... ТЕХТ, о!
свернуть/развернуть ветвь Да я понимаю конеч... [ОпсПлорер 06/03/2002 15:59] # написать ответ
 
Я-ж тож ЗАААА!!!!
 
Ток вот не знаю - не слишком ли много просим?
 
А может с ТХТ тож не просто буит реализовать усе примбамбамсы с вычислениями (суммирование числовых полей или выбирать диапазоны полей даты)и опять таки если к "3456,78 монгольским тугикам" прибавть "25 мартaбря 1800 года" и вычесть упоминавшийся ранее "фаллоимитатор" - скока это буит?
 
1)Прибамбасы в вычислениями, говорите...
На лицо очередная попытка повесить на программу расчет склада и ведение оптовой торговли!
Будет возможность экспортировать и подсчитывать за пределами CASHа кол-во фаллоимитаторов.
А назначение атрибута - отличать операции. Все остальное - сама-сама-сама...)))
 
А то перебор получается, по моему скромному убеждению.
 
Сергеееей, аууу! Как же будет на самом-то деле? ))))
 
2) Дружище, главное сейчас - дождаться отчетов. Там уже станет более понятно, куда и как двигаться!
 
Удачи!
 
P.S. А как же мои любимые повторяющиеся операции с исполнением? )))
свернуть/развернуть ветвь Вступаю! :) [Dervish 06/03/2002 18:23] # написать ответ
 
Извините, что не отвечал по ходу дискуссии: был далеко от компьютера.
 
Давайте отделим мух от котлет:
 
1. Иерархические атрибуты. Вообще, их можно плодить сколько угодно. Доработка программы, конечно же требуется, но (я так подозреваю), она приведёт в конечном итоге к уменьшению размера программы (если не делать что-нить совсем экстравагантное). Основная сложность: как сделать динамическое добавление атрибутов. Так, чтобы при 5000 операций добавление (удаление) атрибута не приводило к многочасовому ожиданию пользователя. Хотя (!) этот вопрос я на обсуждение не выношу, это моя проблема.
 
2. Дополнительные даты/текстовые поля. Та же самая проблема, что и выше. Пока не уверен, что такая модификация программы будет целесообразна.
 
3. Добавление полей количество/цена. Это должно реализовываться ручками, потому что эти два поля напрямую завязаны с суммой операции. Изменение любого из этих полей влечёт изменение суммы и наоборот. Ситуация, на самом деле похожа на ввод сумм при операции перевода между счетами в разных валютах.
 
И, наконец, самое главное. Не просите меня сделать "вычисляемые" поля. Так, чтобы (как в случае количество/цена) в поле можно было бы ввести формулу, по которой бы вычислялось некоторое значение по другим столбцам. Может быть когда-нибудь до этого и дойдём, но, боюсь, не в этой жизни.
 
PS. Если честно, то пока до них (до повторяющихся операций с исполнением) даже руки не дошли. Мне стыдно за задержку с выходом версии 1.3.
 
Нужно еще и определять формат выбираемого юзером поля. Прич если определенный формат выбран для хотяб одного поля в таблице - то есссесьно он таким будет для усех записссей хоч-нехоч.
Можно ток Хайдить/Анхайдить поле и усе.
 
Вот и прикинь - типа три поля запасных - одно Мемо одно Дата и одно Намба...
Ну и чо - богатый выбор? А если надо два поля Намба и одно даты - типа - извини подвинься, или пиши кода три страницы - чоп динамически изменять формат (или на форме делать 10 скрытых полей ввода с разными форматами тогда кода боит пять страниц) про ввод некорретных данных - вощ молчу (Data Type Mismatch)
 
Ток процедура построения формы (а форму приходится строить программно при открытии записи об операции в зависимости от забитых для неё (т.е. -(так её) - операции) атрибутов) грузит машину как белаз сорокач (40 тонн)...
Заманчиво, но каатся это все-ж другая песня...
 
Может в следующей жизни?
Даже просто настраиваемые кэпшены для полей - и то приторррррррммммаааааажжжжииииввввааааеееееееттт (все-ж две таблицы и связь)
 
Если чо- кэпшены надоть держать в реестре, а как тоды на др.машине запускать?
При всех перенастройках программы создавать запись в БД с хранимым файлом *reg с ключами реестра и при запуске базы (не приложения а базы)на др. машине - предлагать записать в реестр настройки...
Во мля народ повеселится... Я прикидываю...
свернуть/развернуть ветвь RE: Список операций [Artem Fedorov 06/03/2002 12:32] # написать ответ
 
Мне кажется, Игорь имеет в виду не тип операции, а возможность вложения в одну операцию нескольких под-операций. Мы как ра обсуждали это не так давно. Идея хорошая.
 
Dervish: Да, обсуждали... Мне тоже кажется, что разговор о том же самом.
свернуть/развернуть ветвь Тогда предлагаю так: [Женя 06/03/2002 12:58] # написать ответ
 
Уточните тогда, как работать будет.
 
Если я правильно понимаю, подоперация должна быть как-то связана с атрибутом(статьей или проектом). Т.е. если выбрана какая-то операция, то в окне операции уже будет установлен такой-то проект/статья/агент. Это действительно ускорит ввод операции. Удобно.
 
Dervish: А вот это неплохая мысль! Спасибо!
свернуть/развернуть ветвь RE: Тогда предлагаю так: [Игорь 06/03/2002 13:42] # написать ответ
 
Когда я предлагал добавить подоперации, я не подумал про возможность связать их с каким-либо атрибутом, а ведь действительно было бы здорово. Но это возможно только при наличии подопераций. Для трех имеющихся операций возможность привязки атрибутов теряет смысл ...
свернуть/развернуть ветвь RE: RE: Список операций [Игорь 06/03/2002 13:38] # написать ответ
 
Совершенно верно, именно вложенность операций я и имел в виду. Сейчас их только три - Приход, Расход и Перевод. Замечательно, вот пусть эти три и остаются, но в пределах каждой хорошо бы иметь возможность задать свои подоперации ... хотя бы одного уровня вложености
 
Dervish: А вот позвольте спросить: допустима ли операция перевода вложенная в операцию расхода? А операция расхода может быть вложена в операцию прихода?
свернуть/развернуть ветвь RE: RE: RE: Список операций [Игорь 07/03/2002 10:17] # написать ответ
 
Нет, разумеется недопустима. Если уж создана подоперация группы "Расход", то она может быть ТОЛЬКО РАСХОДНОЙ. Иначе в этом смысла никакого нет. Введение подопераций ставит своей целью обойти ограничение программы на имеющиеся три определенные операции - "Приход", "Расход" и "Перевод". Мне бы хотелось, чтобы это были не операции, а наименования групп операций. Я бы создал несколько операций прихода от разных источников или, например, несколько операций перевода - "Покупка валюты", "Продажа валюты" и т.д., но сейчас я этого не могу сделать, и вынужден все операции фиксировать только как "Перевод". Мое предложение никаких кардинальных изменений не предполагает. Просто можно будет создать несколько операций группы прихода, несколько операций группы расхода и т.д. Вот и все.
 
Dervish: А что делать, если, например, перевод сопровождался комиссией? Типичный случай: снятие наличных со счёта в банке есть операция перевода. Однако, банк может взять за эту операцию комиссию. Как быть в такой ситуации?
свернуть/развернуть ветвь RE: RE: RE: RE: Список операций [Игорь 11/03/2002 13:25] # написать ответ
 
В такой ситуации я вижу два варианата.
1. Ручной вариант. Данная операция распадается на две: перевод суммы со счета в банке на "счет Наличные" и операция "Взятие комиссии" из группы операций расхода. Обе операции выполняются вручную.
2. Автоматический вариант. Если в программе будет предусмотрено автоматическое формирование порождаемых операций, то формируется только операция перевода, а операция "Взятие комиссии" будет выполнена автоматически.
САМОЕ ГЛАВНОЕ!!!
все вышерассмотренное не имеет никакого отношения к тому, что я предлагал. Операции перевода (прихода, расхода) таковыми и остаются. Просто их будет несколько - несколько операций расхода, несколько перевода и т.д. И все. Ничего кардинально не меняется. Просто учитывать проще. Каждый раз я вижу не только то, что произошла, например, операция перевода, но и то, что это перевод КОНКРЕТНО с банковского счета на счет Наличные.
свернуть/развернуть ветвь Э-эээ позвольте примечание. [Э-э-э-э КсПлорер 06/03/2002 16:15] # написать ответ
 
Логические вопросы...
 
Все дочерние операции имеют атрибуты родительской! - Иначе нужно заводить др. операцию (хотя конеч вопросы и просьбы будут) я чес. скажу - не припомню ситуации, когда я не мог бы повесить любой один из расходов по операции туда-ж куда и всю операцию (хоч потребность разок была)
Сумма совпадать должна, но не обязана. например если сумма родительской операции не введена, то после добавления подчиненных - вычисляется как их сумма. Если введена, но не совпадает - мессэдж бокс - изменить/оставить
 
В графиках обрабатывать ток родительскую операцию - сведения о пордчиненных - справочные и детализирующие.
 
во как...
 
Dervish: А как быть (например) с желанием сделать вложенную операцию, в которой учесть комиссию банка за транзакцию, оформленную как родительская операция?
 
Пример: я покупаю валюту (в обменнике) - операция перевода. Я хочу в эту операцию перевода "встроить" отдельную операцию расхода, в которой отразить налог 1% с покупки иностранной валюты.
 
Другие примеры с безналичными перечислениями и удеражанием комиссии за платёж, я думаю, Вы сможете описать сами.