Экспорт в Excel

Экспорт в Excel Alex 11/08/2003 17:37 #

На мой взгляд, при экспорте в Excel приходы и расходы должны быть в одном столбике с разными знаками, возможно ли сделать настраиваемый/опциональный экспорт в будущих версиях. Это нужно для синхронизации с Palm PocketMoney, там практически такая же структура записей после экспорта, но одно но расходыи приходы одной колонкой, ИМХО это и логичнее.

Dervish: Экспорт/импорт делался так, увы, без учёта особенностей Palm PocketMoney. Не могу пока ответить на ваш вопрос, поскольку экспорт/импорт не предназначался для синхронизации с наладонниками.

А существуют ли другие возможности (интерфейсы) для синхронизации с Palm-ами?

Особенности данных и синхронизация Alex 12/08/2003 12:34 #

Я бы не сказал, что это особенности учета в 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 #

Хм.. Имхо это самое главное, я так и понял, что структура "не правильная"

на мой взгляд.

Разберемся с переводами (трансферами): для счета, с которого произошел перевод-это фактически "расход" только не"вникуда", а на другой счет, для которого это, соответственно, "приход".
На первом счете сумма со знаком "-", на втором со знаком "+". Общая сумма счетов (общий баланс)не изменяется.

Какие плюсы у такой системы учета
1. Все в столбик

2. В БД нет лишних полей
3. Все операции формализованы (сведены к 2ум приход/расход или приход+расход для трансферов)
4. Баланс считается простым суммированием
5. Может еще какие-то есть.

"-" пока не вижу

Вот такие у меня доводы и считаю способ учета одним из ключевых моментов в программе.

К стати остаток после операции иногда называют "Накопительный итог" или "Running balance"

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

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

А если речь, на самом деле, шла только о том, как именно выгружать данные в Excel, то здесь надо учитывать тот факт, что зачастую данные выгружаются для того, чтобы их можно было импортировать в другую базу. Если я буду выгружать операцию перевода как две операции (одна прихода, вторая - расхода), то именно так (и только так) я смогу их впоследствии импортировать в другую базу.

Извините за сумбурность изложения.

Даешь всё в одну колонку ! Alex 15/08/2003 13:10 #

По поводу разорванности - никакой разорванности нет.
Программа при занесение операции перевода (трансфера) делает сразу две записи с признаком "перевод" ("трансфер") и в дальнейшем, при изменении/удалении этой записи, программа изменяет сразу обе записи.

При этом, если удалить/свернуть один счет целиком, то останется половинка записи с приходом или расходом на другом счете и баланс оставшегося счета не изменится. Изменится лишь назначение и тип оставшейся половинки трансфера.

Вот в кратце и все. Вижу в этом вопросе фундаментальную проблему

и готов общаться по e-mail, чтоб не нагружать форум.

Dervish: Да, по-моему эта проблема действительно фундаментальная. Такое впечатление, что мы разговариваем на разных языках.

Например, я не совсем понимаю ваше упоминание про "удаление счёта". Сейчас счёт можно удалить только, если предварительно были удалена все операции по этому счёту.

И уж совсем непонятно, какой смысл вы вкладываете в слова "свернуть счёт". Имеется в виду то, что вы упоминали ранее английским термином RollUp? Если да, то вопрос о том, что при такой свёртке будет потеряна информация по статьям / агентам / проектам остаётся открытым.

Про удаление счета Alex 21/08/2003 10:46 #

Простой пример - временный счет (например с деньгами перекрутится) сделали 45 записей из них 40 трансферов с 10 разных счетов. Период 1-1.5 мес. В конце периода все всем вернули со всеми расчитались - счет лишний, он совершенно не нужен, и вообще этот счет лучше никому не показывать. Как его прибить ?
Исправить все трансферы ? Порядка 40 штук ? Да с 10 разных счетов ?

Хотелось бы иметь возможность решать подобные проблемы "мирно"

.

PS: У меня порядка 60 счетов. в идеале должно быть порядка 100 :-/. Очень жду возможности их структурировать в дерево. Счета-суб счета - субсуб счета и т.д.

Dervish: Проблема. Честно говоря, я не знаю, как лучше её решить. С одной стороны, действительно тянет просто удалить этот счёт, но так, чтобы вторые "концы" операций перевода остались корректными. А с другой стороны, будет ли такое удаление счёта правильным? Ведь часть информации при удалении будет утеряна и безвозвратно!

Не знаю пока, какое решение будет правильным. Надо думать.

Концы от прибитого счета Alex 21/08/2003 17:24 #

Решение есть, в частности оно реализовано в Quiken и PocketMoney

Если перевод (трансфер) в базе делать 2 мя записями(расход на одном счете, приход на другом счете), то проблема решается практически автоматически

. Вот это то место, с которго начинается структура БД, где и приход и расход в одноv поле.

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

Что же касательно совместимости именно с Pocket Money (я понимаю, что необходимость "разделить" операции перевода пополам возникла именно из-за необходимости совместимости с Pocket Money?), то это может быть решено, если сделать отдельно синхронизацию с данными этой программы. Разве нет?

Делить трансфер или нет ??? Alex 25/08/2003 18:33 #

Желаю только добра!

Да черт с ним - с Pocket Money, в конце концов если есть экспорт в Ексель можно все что угодно синхронизировать.

Речь идет именно о прибивании счета. Перетаскивание в мусорную ветку годится и нормально для "нормальных" счетов, а если в счете кое-что  такое, что не для посторонних глаз. Кроме этого размер БД ? Сейчас у меня 65 кило. Я понимаю, что это ничтожно мало, но в 1-2, или 5 МБ. Я думаю, что достигну этого счастья примрно через год-1,5.

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

>Dervish  но позволяет свести на нет все усилия по налаживанию учёта, ведь при этом теряется часть информации и весьма существенная.

Это смотря у кого какие цели учета, если кому-то интересно сколько он на молоко и водку тратит, то имхо это интересно смотреть в динамике, сколько за прошлый период потратил, сколько за этот, ага стал больше на молоко тратить чем на водку - позитив на лицо. Но зачем же для этого базу за последние 5 лет держать ? Сделал отчет за год (в том же екселе) и записал рядом с базой отчеты, чтоб через годик их посмотреть и с текущими сравнить.

Может я,конечно,  чего не понимаю...

Очень хочется (уже) свертывать записи в счете и счета же прибивать.

Еще пример: Есть клиент, с ним сложные взаиморасчеты, опять же много трансферов. Все, расчитались, закрыли все вопросы. расписки друг-другу отдали, претензий нет, а историю стремно хранить и не только на компьютере, а на Флэшке в сейфе/под яблоней на даче. Что делать прикажете ?

PS: Заботюсь о юзверях

Dervish: Ой, до чего же мне не нравится слово "юзверь"!!! Разве ж можно живых людей таким словом называть?

Я правильно понял, что всё, что вам нужно, это чтобы (а) можно было удалять счёт, сразу же вместе со всеми операциями по счёту и чтобы при таком удалении (б) операции переводов на этот счёт (с этого счёта) по остающимся счетам превращались в операции расхода (прихода) соответственно?

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

Так как в первой версии нет undo/redo, я посчитал, что удалять сразу массивы операций, это очень и очень опасное дело. Во второй версии undo/redo уже реализовано, так что можно говорить и о действиях пользователя сразу над группой записей. Таким образом получается, что теперь нет сдерживающих факторов к тому, чтобы удалять счёт сразу с операциями по этому счёту попутно исправляя операции перевода.

Кстати, во второй версии размер файла базы данных вырастет. Думаю, что рост составит примерно 2,5 ~ 3 раза.

Высшая мера утверждена Alex 26/08/2003 11:49 #

Спсибо за объективный подход и понимание.

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

Как будет реализовано мне конечно все равно, главное что б не сильно затянулись сроки, а что касается любви к исскуству программирования, то я его не очень люблю тем более, что тачки сейчас настолько быстрые, что смысла нет долго думать над оптимизацией скорости ради 1-2%.

Dervish: А вот со свёрткой давайте подождём. И не потому, что мне хочется повредничать, а исключительно из-за сроков.

Что касательно оптимизации, уверяю вас, что мой подход к ней очень взвешенный: если я и берусь что-то оптимизировать, то только тогда, когда на моём компьютере (P-III, 850 MHz) программа тормозит. Только тогда.

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

Форум Экспорт в Excel