За последние 60 дней ни разу не выходила
Сайт листа:
http://www.dervish.ru/
Открыт:
30-01-2004
Пре-модерация: Нет
Адрес для писем в лист: comp.soft.others.abilitycash-list@subscribe.ru
Адрес
модератора: comp.soft.others.abilitycash-owner@subscribe.ru
Наверное,...
..пришло время подправить планы. Мне не хотелось бы делать такое представление,
как в п.5 по целому ряду причин. В том числе потому, что, как мне представляется,
в альфа-версии реализовано более удачное представление.
Что-то, действительно,...
..великоватая \"погрешность\" получилась. Вообще, хотелось бы разобраться с этим
подробнее.
Константин, а можно получить у вас дополнительные материалы? Скажем, скриншот
или (в идеале) пример базы данных с такими симптомами?
Впрочем, наверное я лучше отпишу на e-mail по этому вопросу.
Планы
В Ваших планах в п.5 есть альтернативное представление страницы счетов
Это отражает суть моего предложения - при таком представлении подобная ошибка
не должна возникнуть.
P.S. Если я конечно прав насчет алгоритма, может просто мой компьютер забыл таблицу
умножения? :)
Ноль -в любой валюте ноль
Если у меня сложная структура счетов, в которой счет "Баланс" включает
в себя "Актив" и "Пассив", которые содержат др. счета в различных
валютах(RUR USD EUR), то когда на счете Баланс 0.00 RUR я ожидаю что при пересчете
в USD или EUR результат будет 0.00 USD и 0.00 EUR ЭТО ОЧЕВИДНО! однако возможны
варианты... 411 USD и -112 EUR можно было бы ожидать погрешностей округления
но во первых не в бухгалтерской программе, и во вторых не в таких суммах. Как
мне кажется алгоритм расчета такого рода сумм в программе испльзует сложение
промежуточных итогов. А что если формировать промежуточные итоги по каждой валюте,
конвертировать только для вывода на экран, и для получения глобальных сумм использывать
промежуточные НЕ КОНВЕРТИРОВАННЫЕ, тогда ошибки не будут складываться и "преумножаться".
P.S. У кого есть лишние 411 USD или хотя бы 112 EUR :)
Шаблоны операций
Вроде как Dervish грозился сделать шаблоны операций, если не в ближайшей сборке,
то во всяком случае в одной из ближайших версий.
таким образом программа должна иметь следующие закладки свер
"Счета" - то что есть сейчас
"Журнал операций" - то что нынче называется "Операции".
"Операции" - дерево стандартных операций, страница для для настроек
стандартных операций
и так далее что есть... Конечно еще хотелось бы журнал проводок, но это уж совсем
бухгалтерия....
продолжение
Хотя если в денежную программу ввести серию стандартных шаблонных операций, чтобы
по сто раз не вводить одно и то-же (с определенными по умолчанию реквизитами),
если операция стандартная. И тоже выстроить их в виде дерева.
Например, покупаю я строительный материал для дачи, выбираю из древовидного шаблона
пункт стройматериалы для дачи. А у меня автоматически заполняются все необходимые
для этой операции поля: Расход, со счета "наличные", проект "строительство
дачи", объект "дача", статья расхода: "материалы/стройматериалы",
допустим делаю небольшую поправку "материалы/стройматериалы/кирпич",
для уточнения назначения платежа.
И всё. Да, конечно, потребуются дополнительные предварительные настройки, но
это окупается потом скоростью ввода.
Желательно, чтобы такой шаблон мог сделать несколько связанных операций по разным
счетам.
Именно поэтому в классической бухгалтерии есть отдельно журнал проводок и журнал
операций.
(Ладно, это я уже в дебри полез)
<i>Но если уж очень-очень нужно, то, думаю, следует создать классификатор и установить
в нём признак "Не разделять по виду операции".</i>
Так я и сделал, искуственно введя приход и расход как элемент дерева (отрицательно,
что показывается все дерево при заполнении операции)
продолжение
<i>>Кстати, возвращаясь к вашему вопросу, я себе не представляю, как это одна
и та же статья может быть и статьёй прихода и статьёй перевода. Нелогично выходит.</i>
Если рассматривать классическую бухгалтерию, то приход - это результат перевода,
ибо ни что ни откуда само по себе не берется. В классическом учете денег принцип
двойной записи не соблюдается (то есть налицо разрывы учета (учитывается не всё,
а только то, что нужно)), и это понятно, потому, что иначе будет до такой степени
всё сложно, что ни какого учета не захочется.
На самом деле очень часто требуются одни реквизиты в счете с которого перечисляются
деньги и совсем другие реквизиты на счете, на который перечисляются деньги. Этого
можно в данном случае достигнуть только отдельной операцией прихода и отдельной
операцией расхода.
Мысль понятна
<i>>В этом случае я бы поступал так: в момент начисления заработной платы
я вводил бы сумму начисленной зарплаты в виде невыполненной операции прихода.
А в момент выплаты, я отмечал бы эту операцию как выполненную.</i>
Начисленное и выплаченное совсем может не совпадать по сумме (накапливается одними
частями, а выплачивается другими частями), и поэтому такой способ не особо подходит.
Поэтому был выбран более бухгалтерский способ в виде отдельного счета, и перевода
со счета "начислено" на счет "наличные" (кстати, кое-что
со счета "начисленные" переводится на погашение кредита напрямую, минуя
наличные).
Подходов может быть много для организации учета.
