создать новую тему раскрыть все
свернуть/развернуть ветвь Экспорт в Excel [Alex 11/08/2003 17:37] # написать ответ
 
На мой взгляд, при экспорте в Excel приходы и расходы должны быть в одном столбике с разными знаками, возможно ли сделать настраиваемый/опциональный экспорт в будущих версиях. Это нужно для синхронизации с Palm PocketMoney, там практически такая же структура записей после экспорта, но одно но расходыи приходы одной колонкой, ИМХО это и логичнее.
 
Dervish: Экспорт/импорт делался так, увы, без учёта особенностей Palm PocketMoney. Не могу пока ответить на ваш вопрос, поскольку экспорт/импорт не предназначался для синхронизации с наладонниками.
 
А существуют ли другие возможности (интерфейсы) для синхронизации с Palm-ами?
 
Я бы не сказал, что это особенности учета в PocketMoney - это особенности учета за границей см. Quiken и пр.
ИМХО без учета в столбик операций с разными знаками программу не примут "там".
 
Если Вы еще не рассматривали PocketMoney - очень рекомендую, там много полезного, в том числе и механизм удаления счета с записями.
 
Механизмов синхронизации много, но наиболее удобным считаю такой как в PocketMoney (могу отписать подробней). Коротко он экспортирует в 2 формата CSV и QIF (Quiken), и импортирует из них же. CSV файл в Excele очень похож на то, что делает Cash.
 
Dervish: Понятно, спасибо.
 
Мне тоже казалось, что для западного рынка придётся "разносить" суммы прихода и расхода в разные колонки. По крайней мере, я видел, что так сделано в других финансовых программах. Наверное, я сделаю такой показ данных опциональным, всё-таки у нынешнего подхода тоже есть свои плюсы.
свернуть/развернуть ветвь Разные колонки [Alex 13/08/2003 10:30] # написать ответ
 
Почему в разные, я говорил, что в одну колонку нужно и приходы и расходы, в том числе и при экспорте в Excel.
 
Dervish: Извините, я неправильно понял.
 
Дело в том, что структура таблицы Excel практически полностью повторяет структуру базы данных. Внести изменения в структуру Excel в принципе возможно, только не совсем понятно, что именно надо делать с операциями перевода.
свернуть/развернуть ветвь Еще о колонках [Alex 14/08/2003 01:06] # написать ответ
 
Хм.. Имхо это самое главное, я так и понял, что структура "не правильная" Well на мой взгляд.
 
Разберемся с переводами (трансферами): для счета, с которого произошел перевод-это фактически "расход" только не"вникуда", а на другой счет, для которого это, соответственно, "приход".
На первом счете сумма со знаком "-", на втором со знаком "+". Общая сумма счетов (общий баланс)не изменяется.
 
Какие плюсы у такой системы учета
1. Все в столбик Well
2. В БД нет лишних полей
3. Все операции формализованы (сведены к 2ум приход/расход или приход+расход для трансферов)
4. Баланс считается простым суммированием
5. Может еще какие-то есть.
 
"-" пока не вижу
 
Вот такие у меня доводы и считаю способ учета одним из ключевых моментов в программе.
 
К стати остаток после операции иногда называют "Накопительный итог" или "Running balance"
 
Dervish: Основной минус изложенного вами подхода как раз в том, что в этом случае операция перевода становится "разорванной". Она разделяется на две половинки, которые независимы друг от друга. Тогда становится возможным производить какие-то действия отдельно по каждой половинке операции прихода.
 
А теперь давайте посмотрим на типичный вид перевода: вы заходите в обменный пункт чтобы продать доллары (и получить за них рубли). Я думаю, что вы со мной согласитесь, что в реальной жизни это неделимая операция. А раз она неделима в реале, то и в учёте это должна быть одна запись. Иначе что получается? Иначе, если удалить одну из половинок операций, получится, что вы отдали доллары, но рубли не получили. Или наоборот, рубли пришли а доллары так и остались в кошельке.
 
А если речь, на самом деле, шла только о том, как именно выгружать данные в Excel, то здесь надо учитывать тот факт, что зачастую данные выгружаются для того, чтобы их можно было импортировать в другую базу. Если я буду выгружать операцию перевода как две операции (одна прихода, вторая - расхода), то именно так (и только так) я смогу их впоследствии импортировать в другую базу.
 
Извините за сумбурность изложения.
 
По поводу разорванности - никакой разорванности нет.
Программа при занесение операции перевода (трансфера) делает сразу две записи с признаком "перевод" ("трансфер") и в дальнейшем, при изменении/удалении этой записи, программа изменяет сразу обе записи.
 
При этом, если удалить/свернуть один счет целиком, то останется половинка записи с приходом или расходом на другом счете и баланс оставшегося счета не изменится. Изменится лишь назначение и тип оставшейся половинки трансфера.
 
Вот в кратце и все. Вижу в этом вопросе фундаментальную проблему Well и готов общаться по e-mail, чтоб не нагружать форум.
 
Dervish: Да, по-моему эта проблема действительно фундаментальная. Такое впечатление, что мы разговариваем на разных языках.
 
Например, я не совсем понимаю ваше упоминание про "удаление счёта". Сейчас счёт можно удалить только, если предварительно были удалена все операции по этому счёту.
 
И уж совсем непонятно, какой смысл вы вкладываете в слова "свернуть счёт". Имеется в виду то, что вы упоминали ранее английским термином RollUp? Если да, то вопрос о том, что при такой свёртке будет потеряна информация по статьям / агентам / проектам остаётся открытым.
свернуть/развернуть ветвь Про удаление счета [Alex 21/08/2003 10:46] # написать ответ
 
Простой пример - временный счет (например с деньгами перекрутится) сделали 45 записей из них 40 трансферов с 10 разных счетов. Период 1-1.5 мес. В конце периода все всем вернули со всеми расчитались  - счет лишний, он совершенно не нужен, и вообще этот счет лучше никому не показывать. Как его прибить ?
Исправить все трансферы ? Порядка 40 штук ? Да с 10 разных счетов ?
 
Хотелось бы иметь возможность решать подобные проблемы "мирно" Well.
 
PS: У меня порядка 60 счетов. в идеале должно быть порядка 100 :-/. Очень жду возможности их структурировать в дерево. Счета-суб счета - субсуб счета и т.д.
 
Dervish: Проблема. Честно говоря, я не знаю, как лучше её решить. С одной стороны, действительно тянет просто удалить этот счёт, но так, чтобы вторые "концы" операций перевода остались корректными. А с другой стороны, будет ли такое удаление счёта правильным? Ведь часть информации при удалении будет утеряна и безвозвратно!
 
Не знаю пока, какое решение будет правильным. Надо думать.
 
Решение есть, в частности оно реализовано в Quiken и PocketMoney Well
 
Если перевод (трансфер) в базе делать 2 мя записями(расход на одном счете, приход на другом счете), то проблема решается практически автоматически Well. Вот это то место, с которго начинается структура БД, где и приход и расход в одноv поле.
 
Dervish: И всё-таки я считаю, что делать операцию перевода в виде двух половинок будет неправильным. А возможность "прибить" счёт, удалив все "половинки" операций, она, может быть и греет душу, но позволяет свести на нет все усилия по налаживанию учёта, ведь при этом теряется часть информации и весьма существенная. Да и, собственно, зачем вообще удалять счета, по которым есть операции? Неужели они мешают? Ну а если всё-таки мешают, то подождите второй версии, там счета будут организованы иерархически и их можно будет перетащить в "мусорную" ветку, в которой они наверняка не будут мешать.
 
Что же касательно совместимости именно с Pocket Money (я понимаю, что необходимость "разделить" операции перевода пополам возникла именно из-за необходимости совместимости с Pocket Money?), то это может быть решено, если сделать отдельно синхронизацию с данными этой программы. Разве нет?
 
Желаю только добра! Well
 
Да черт с ним - с Pocket Money, в конце концов если есть экспорт в Ексель можно все что угодно синхронизировать.
 
Речь идет именно о прибивании счета. Перетаскивание в мусорную ветку годится и нормально для "нормальных" счетов, а если в счете кое-что  такое, что не для посторонних глаз. Кроме этого размер БД ? Сейчас у меня 65 кило. Я понимаю, что это ничтожно мало, но в 1-2, или 5 МБ. Я думаю, что достигну этого счастья примрно через год-1,5.
 
Имхо как-то от мусора все равно придется избавлятся, просто заведением новой базы проблему можно решить, но опять вносить счета, агентов и т.п.
 
>Dervish  но позволяет свести на нет все усилия по налаживанию учёта, ведь при этом теряется часть информации и весьма существенная.
 
Это смотря у кого какие цели учета, если кому-то интересно сколько он на молоко и водку тратит, то имхо это интересно смотреть в динамике, сколько за прошлый период потратил, сколько за этот, ага стал больше на молоко тратить чем на водку - позитив на лицо. Но зачем же для этого базу за последние 5 лет держать ? Сделал отчет за год (в том же екселе) и записал рядом с базой отчеты, чтоб через годик их посмотреть и с текущими сравнить.
 
Может я,конечно,  чего не понимаю...
 
Очень хочется (уже) свертывать записи в счете и счета же прибивать.
 
Еще пример: Есть клиент, с ним сложные взаиморасчеты, опять же много трансферов. Все, расчитались, закрыли все вопросы. расписки друг-другу отдали, претензий нет, а историю стремно хранить и не только на компьютере, а на Флэшке в сейфе/под яблоней на даче. Что делать прикажете ?
 
PS: Заботюсь о юзверях Well
 
Dervish: Ой, до чего же мне не нравится слово "юзверь"!!! Разве ж можно живых людей таким словом называть?
 
Я правильно понял, что всё, что вам нужно, это чтобы (а) можно было удалять счёт, сразу же вместе со всеми операциями по счёту и чтобы при таком удалении (б) операции переводов на этот счёт (с этого счёта) по остающимся счетам превращались в операции расхода (прихода) соответственно?
 
Я могу это сделать во второй версии программы. Это возможно. А как именно это будет делаться, согласитесь, это не суть важно.
 
Так как в первой версии нет undo/redo, я посчитал, что удалять сразу массивы операций, это очень и очень опасное дело. Во второй версии undo/redo уже реализовано, так что можно говорить и о действиях пользователя сразу над группой записей. Таким образом получается, что теперь нет сдерживающих факторов к тому, чтобы удалять счёт сразу с операциями по этому счёту попутно исправляя операции перевода.
 
Кстати, во второй версии размер файла базы данных вырастет. Думаю, что рост составит примерно 2,5 ~ 3 раза.
 
Спсибо за объективный подход и понимание.
 
К пунктам а и б хотелось бы добавить (в)- свертку операций внутри счета, когда остается в счете одна запись с итоговой суммой (балансом по счету), причем (в) должен удовлетворять (б).
 
Как будет реализовано мне конечно все равно, главное что б не сильно затянулись сроки, а что касается любви к исскуству программирования, то я его не очень люблю тем более, что тачки сейчас настолько быстрые, что смысла нет долго думать над оптимизацией скорости ради 1-2%.
 
Dervish: А вот со свёрткой давайте подождём. И не потому, что мне хочется повредничать, а исключительно из-за сроков.
 
Что касательно оптимизации, уверяю вас, что мой подход к ней очень взвешенный: если я и берусь что-то оптимизировать, то только тогда, когда на моём компьютере (P-III, 850 MHz) программа тормозит. Только тогда.
 
А длинные сроки отчасти ещё связаны со средой программирования, ведь мне приходится каждый контрол ручками размещать. Очень много времени уходит на продумывание интерфейса. Бывает, что более или менее приемлимое решение я нахожу только, наверное, раза с третьего.