Re: financial library.
I have not looked at those. I was not aware that there was equations to be found here. Terry Boldt wrote: > On Sun, 28 Jan 2001, you wrote: > > I found this while looking for finanical equations on the web. I have > > not had much luck with the equations yet. > > > > The api should match this one . > > > > http://www.idexsoft.com/index.html > > > > > > Have you checked out the financial equations in the financial calculator built > into the latest development version of gnucash? I don't know which financial > equations you are looking for, but the equations in that calculator are > documented in the source. I have been using the equations for over ten years > and in that time have matched what the banks report on all statements. Also the > equations were originally used on the Hewlett-Packard financial calculators and > used by thousands in the financial industries for more than ten years. > > Are you looking for equations other than those used in the gnucash calculator? ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: AccrInt
Phillip J Shelton <[EMAIL PROTECTED]> writes: >"John S. Dey" wrote: >> Its been brought up before on the gnumeric mailing list, that if, in >> fact, errors are detected in Excel, what should the gnumeric >> implementation do? This is an issue that probably has already been >> addressed so for what its worth I would implement the error in the >> function (provided it can be replicated) and then add a feature that >> would provide the correct calculation. > >I don't intend to un-Excel clone gnumeric. If the spreadsheet functions >need errors coded in then that is what has to happen. I would much prefer that both compatible and correct versions be implemented. There should be a over-all option to select which set is used (the same way that setting the environment variable POSIXLY_CORRECT changes the behavior of several other GNU programs). If convenient, there could also be individual options to select versions of individual features. I can offer two reasons: First, some of us are more interested in correctness than Excel compatibility. Second, we can assume that Microsoft application writers have some interest in correctness (at least, more interest than their colleagues working on operating systems :-). Eventually, they are likely to issue a new version of Excel with the correct implementation. At that point, Gnumeric will need the other implementation for compatibility as well as correctness. - Jim Van Zandt p.s. A run-time option would be nice. However, a configuration-time option would be better than nothing. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: AccrInt
On Sun, Jan 28, 2001 at 09:14:12PM -0500, James R. Van Zandt wrote: > > I would much prefer that both compatible and correct versions be > implemented. There are two distinct questions. 1) replicate poor function interfaces 2) replicate calculation errors The former is a partial requirement. We have no interest in the later. > I can offer two reasons: First, some of us are more interested in > correctness than Excel compatibility. Second, we can assume that > Microsoft application writers have some interest in correctness (at > least, more interest than their colleagues working on operating > systems :-). Eventually, they are likely to issue a new version of > Excel with the correct implementation. Our approach to (1) has been to support two interfaces. One to match XL and another to supply something more useful. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: AccrInt
Phillip J Shelton writes: > I don't intend to un-Excel clone gnumeric. If the spreadsheet functions > need errors coded in then that is what has to happen. Then I will neither use nor recommend gnumeric. I have no objection to bug-for-bug compatibility as a _option_, but deliberately coding buggy default behavior is a horrendous idea. -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
GnuCash 1.4.10 is released.
___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
transaction-report.scm
Birger Retterstøl Olaisen writes: > I've made some modifications to the file > share/gnucash/scm/report/transaction-report.scm to add the posibility to sort > by account number. These modifications may perhaps not be well coded (it's my > first attempt to code in sceme, so I don't know the style) but they work. The transaction report is just about to be pulled apart and rewritten in any case, so unfortunately your patch can't go in to the development version. However, we might be able to look at adding your code to the next 1.4.x release, if we make another one (1.4.x is getting to the "ancient" stage, and we are heading towards a 1.5.x code freeze in preparation for a 2.0 stable release in a couple months time hopefully). Thanks for your efforts though! We do appreciate it, but it does pay to check the development version to see whether your feature has already been added, or the underlying way of doing things has changed. Robert Merkel [EMAIL PROTECTED] "We are excited and optimistic about its usage going forward and, yes, we can teach penguins the military close-order drill", Mark Norton, US Department of Defense. ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
1.5 code-freeze for 2.0? Need a better general QIF importer
Robert Graham Merkel <[EMAIL PROTECTED]> writes: > However, we might be able to look at adding your code to the next > 1.4.x release, if we make another one (1.4.x is getting to the > "ancient" stage, and we are heading towards a 1.5.x code freeze in > preparation for a 2.0 stable release in a couple months time > hopefully). One piece of functionality which I would hope would make it into a code-freeze would be the ability to load (read: merge) Bank-generated QIF files into already-existing accounts. Most of the code is there now; the only issue is that there is no way to check a QIF import against the current account tree for duplicate transactions. I would hope that this functionality would take a higher priority that, say, SQL (or even client-server). I say this because I believe more people are interested in syncing their accounts with NetBank, Vanguard, ChaseOnline, E*Trade, and other online bank systems than they are in using a DB to store their transactions or client-server or multiple users. Previous discussions led me to believe that this was in the works. If I was wrong, I suppose that I should spend the time to tear apart the QIF importer and generalize it. My personal view is that the current functionality of the QIF importer is really a misnomer. It does not really import QIF, it initializes an account tree based upon a set of QIF files. Moreover, this functionality is really iseful only once, to move your data from Quicken to GnuCash. I'd like to change the functionality (including menu options). I want to add a new menu option, "Initilize from QIF" that basically runs the current importer, and then change the existing "QIF Import" button so that it performs a QIF load-and-merge-into-existing-accounts. The hardest part I can see is determining how to notice a duplicate transaction. For example, if I'm making a transfer from e.g. NetBank to Vanguard, the transaction might appear in my NetBank account on a different day than it appears in my Vanguard account. So, how would GnuCash tell that these are the same transaction instead of a repeated transaction on different days? Before I delve into the code, do people think that I'm going down the right track here? Is there someone actually working on this at the moment to make the upcoming code freeze? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: 1.5 code-freeze for 2.0? Need a better general QIF importer
On Mon, Jan 29, 2001 at 05:57:58PM -0500, Derek Atkins wrote: > One piece of functionality which I would hope would make it into a > code-freeze would be the ability to load (read: merge) Bank-generated > QIF files into already-existing accounts. Most of the code is there > now; the only issue is that there is no way to check a QIF import > against the current account tree for duplicate transactions. You're right. In fact, the additional code doesn't belong in the QIF importer at all; rather, we need a generalized account-tree merging routine that merges two gnucash account groups. At the moment, the interface the QIF importer uses is xaccGroupMergeAccounts. I would like a nice graphical replacement that provides the same functionality but handles eliminating duplicate transactions based on matching heuristics. > I would hope that this functionality would take a higher priority > that, say, SQL (or even client-server). The DB and multiuser stuff aren't going into gnucash-2.0. That's just speculation, prototyping, and planning for the future. The set of folks that have been committing code for gnucash-2.0 doesn't really overlap the set of people discussing the database and multiuser changes. Please don't misunderstand: I am very happy that people have started addressing the SQL and multiuser issues, and that work is very valuable. But I'm also glad that the people who are working on 2.0-critical projects aren't really part of the discussion :) > Previous discussions led me to believe that this was in the works. > If I was wrong, I suppose that I should spend the time to tear apart > the QIF importer and generalize it. Please don't. I think it's important to add this functionality, but I feel very strongly that it is independent from the QIF importer. Keep it separate, and keep the API the same as xaccGroupMergeAccount's. I still have this on my personal list of things to do, but I have a lot of other things going on right now, mainly focusing on the reporting and networking infrastructure. If you have the time and motivation to do it I'd be happy to help in any way I can. > My personal view is that the current functionality of the QIF > importer is really a misnomer. It does not really import QIF, it > initializes an account tree based upon a set of QIF files. That's explicitly what it was designed to do, because the main goal of importing QIF files is to make gnucash accessible to people who use Quicken. The role of QIF files as a network file format is very important, but importing them flawlessly is the second-most important kind of QIF importing IMO. I think that (though there are still a few bugs left) the basic "import my Quicken data" functionality works pretty well so it's a good time to add the other. > The hardest part I can see is determining how to notice a duplicate > transaction. Welcome to a very difficult problem in heuristic matching. That's why I focused on the "other" kind of QIF importing first. Bill Gribble ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: 1.5 code-freeze for 2.0? Need a better general QIF importer
I'd like to see the QIF importer automagically assign the appropriate tax category to imported accounts, though, I'm not sure there is sufficient information in the QIF file. Several months ago, I looked at the QIF code for a few hours, but I really couldn't understand what was going on. Perhaps a set of default accounts with pre assigned tax categories would be appropriate? Gilligan Bill Gribble wrote: On Mon, Jan 29, 2001 at 05:57:58PM -0500, Derek Atkins wrote: > One piece of functionality which I would hope would make it into a > code-freeze would be the ability to load (read: merge) Bank-generated > QIF files into already-existing accounts. Most of the code is there > now; the only issue is that there is no way to check a QIF import > against the current account tree for duplicate transactions. You're right. In fact, the additional code doesn't belong in the QIF importer at all; rather, we need a generalized account-tree merging routine that merges two gnucash account groups. At the moment, the interface the QIF importer uses is xaccGroupMergeAccounts. I would like a nice graphical replacement that provides the same functionality but handles eliminating duplicate transactions based on matching heuristics. > I would hope that this functionality would take a higher priority > that, say, SQL (or even client-server). The DB and multiuser stuff aren't going into gnucash-2.0. That's just speculation, prototyping, and planning for the future. The set of folks that have been committing code for gnucash-2.0 doesn't really overlap the set of people discussing the database and multiuser changes. Please don't misunderstand: I am very happy that people have started addressing the SQL and multiuser issues, and that work is very valuable. But I'm also glad that the people who are working on 2.0-critical projects aren't really part of the discussion :) > Previous discussions led me to believe that this was in the works. > If I was wrong, I suppose that I should spend the time to tear apart > the QIF importer and generalize it. Please don't. I think it's important to add this functionality, but I feel very strongly that it is independent from the QIF importer. Keep it separate, and keep the API the same as xaccGroupMergeAccount's. I still have this on my personal list of things to do, but I have a lot of other things going on right now, mainly focusing on the reporting and networking infrastructure. If you have the time and motivation to do it I'd be happy to help in any way I can. > My personal view is that the current functionality of the QIF > importer is really a misnomer. It does not really import QIF, it > initializes an account tree based upon a set of QIF files. That's explicitly what it was designed to do, because the main goal of importing QIF files is to make gnucash accessible to people who use Quicken. The role of QIF files as a network file format is very important, but importing them flawlessly is the second-most important kind of QIF importing IMO. I think that (though there are still a few bugs left) the basic "import my Quicken data" functionality works pretty well so it's a good time to add the other. > The hardest part I can see is determining how to notice a duplicate > transaction. Welcome to a very difficult problem in heuristic matching. That's why I focused on the "other" kind of QIF importing first. Bill Gribble ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel -- Gilligan | __o .oooO /| _ \<,_ ( ) /p|\ (_)/ (_) \ ( Oooo. / | \ \_) ( ) ) / [EMAIL PROTECTED] (_/ [EMAIL PROTECTED]
