Re: price.date, transaction.post_date and neutral time
Wm via gnucash-devel schreef op 13-02-18 om 17:10: On 13/02/2018 09:12, Alen Siljak wrote: - we enter the investments we own, i.e. Stocks Fund, Bonds Fund, Direct Bond, favorite company ABC stock, etc. - we link the investments (by symbol) to the allocation classes above. Stocks Fund => stocks Bonds Fund => bonds Direct Bond => bonds ABC => stocks - we get the latest prices That's looking self referential to me as your plan allows for a 1.75% government bond to be called a stock and a stock to be called a bond. all a bit pointless. All that computer software needs to do (and, deep into 21st century this is the least I'd expect my personal finance app to do) is to calculate the current value of the holdings, therefore asset classes, and say: "you have 50K in investments, out of which 30% is in stocks and 70% in bonds, while your allocation is 10%/90%". Isn't that just back referencing ? I own a dog, I check my dog ownership and find I own a dog. Neither I or the dog should be surprised. Not really, because the value of the portfolio assets (and therefore the value of the different asset classes) change over time. Say my target asset allocation is 10%/90% (as above) and that is the ratio in which I divide the amount I use buying my assets (say $100). However, I don't own $90 of stocks, but rather 2 stock units priced at $45. The same for my bond assets (e.g. half a bond currently priced at $20). Over time the prices of the underlying assets in my portfolio change. For instance, during recession and with quantitative easing in place, bond prices climbed while equity prices dropped. So now my 2 stock units are only worth $60 total, while my bond category assets climbed to $30. All that Alen is saying that he wants a report which compares my target ratio of 10/90 with my current value ratio of 33/67, as this may lead to a rebalancing of the portfolio. -- Mark ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 2/13/2018 4:53 PM, Matt Graham wrote: 😊 I think I would love to sit down in a pub with the three of you (Wm, Adrien, and Mike). I think we could have such awesome semi-drunken discussions about the nature of life, the universe and everything! I think you have basically answered my question, and I think we all basically agree on the rough direction things *should* go in (separate interacting packages). I’m just not sure how to help make it happen (I’m an enthusiastic amateur when it comes to programming). I think I’ll start by updating the budget part of the tuts and concept guide like I have promised elsewhere, and then start looking into how the C++ modules have been structured (to see what connection will be possible within the 3.0 releases). Thanks and regards, Well of course I am not an amateur, it is how I used to make my living. But I can't help out with program design/coding unless/until I can get bandwidth here a home < unwilling to cut down enough large trees to get a "window" for satellite > But besides being a senior systems analyst (programs) also a senior analyst (business -- the part that comes before) A comment on the third part --- HOW the process of feeds and their reception is handled. That can be deferred for now and at the beginning can assume manual because whether "job scheduling" is possible is more or less OS dependent. For example, I haven't a clue how for Windows could have a job submit (other jobs), tell whether other jobs were running or had completed and if so, whether successfully, etc. That I knew very well how to do this under MVS/XA (a mainframe OS) and am pretty sure I could figure it out for a 'nix is besides the point. Remember (an important point) a feed can FAIL. Not only once the program tries to bring it in but it could have failed in "input editing". In the initial project phase we might better assume that a human is running these things and will not start the next step of the process until seeing that predecessor steps worked. How an automated system is stopped part way and resumed after a "fix" is a project in itself. I'm the sort of guy who used to get woken up in the middle of the night when the programmers on standby couldn't fix the problem. Michael ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
😊 I think I would love to sit down in a pub with the three of you (Wm, Adrien, and Mike). I think we could have such awesome semi-drunken discussions about the nature of life, the universe and everything! I'm in London. Mike is in a Trump voting bit of Merka. Don't know where Adrien is and he shouldn't have to say. I am NOT in a "Trump voting bit of Merka". Not only in one of the "bluest" of the blue states but in a county of that state where on primary election day Bernie had an absolute majority of all votes cast (for all candidates in all parties). Here, people organized FCCPR (Franklin County Continuing the Political Revolution) BEFORE the general election. Not to oppose Trump (didn't know/expect he would win) but intended to try to keep Hilary's feet to the fire on the program. Of course the focus of FCCPR is now different. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
On 2/13/2018 9:49 PM, Wm via gnucash-devel wrote: Why are you blaming the workers rather than the employers? Why do you think a piece of software can help if you are shitting on your employees? Mike, is this what you expected as a response? Adrien appears to be a person that trusts no-one. Welcome to the tacky politics of Trumpian merka :( Absolutely not, it is your response I find surprising. Problems do not arise just because employers are sh*tting on employees << this is NOT to say that some employers don't do exactly that >> However an auditor should NOT approve use of a system without the sort of controls we are talking about, limiting access to those who have need, etc. One of the organizations where I am on committees, etc. (and have been on the board, and in the aftermath aiding the new treasurer recover) was hit by embezzlement by an office manager, from which a decade later we have not fully recovered in the financial sense*. Trusted with access to which she should not have been trusted. * We agreed to a plea bargain "no jail" in exchange for repayment of what she stole (working over time) as if in jail we wouldn't have gotten even THAT back. But what she directly stole was only about half the damage as payments that should have been made to governmental bodies weren't and though those bodies agreed to waive penalties still had to pay the interest on the amounts owed as well as the amounts. The bank involved agreed to lend us the money no interest for a number of years, but still had to be paid back. The total we had to make up close to a year's budget! ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: Planned MAJOR OUTAGE: Thursday 08th of February, 17:00 - 19:00 UTC
John Ralls writes: > I think the only thing there that will impact us is bugzilla. We should really start thinking about running our own BZ instance, assuming we can get a DB Dump from GNOME. > Regards, > John Ralls -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 warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scope of GNUCash
> On Feb 13, 2018, at 8:49 PM, Wm via gnucash-devel > wrote: > > On 13/02/2018 15:30, Adrien Monteleone wrote: >> Michael, >> I agree completely on the separation point, especially with regard to >> controls. > > If you agree on that you are an idiot, I’m not sure why your tone is the way it is. I noticed it changed yesterday and I was quite surprised. I’ve seen several threads where you are replying in a very negative and rude tone. Direct personal attacks and cursing (from another thread on the dev list) are not appropriate. > Mike's POV is (if I understand correctly over a period of time) mainly a > charitable one. Accounting controls are not just for non-profits, far from it. It’s a basic subject taught in accounting classes. If you found an accounting textbook that didn’t cover the subject, I’d say that book was incomplete. There’s even an entire specialty of ‘forensic accounting’ and they don’t just work with non-profits. > >> I’ve seen first hand when sales clerks have the ability to void and edit >> their own transactions from a point of sales system. I can’t imagine the >> damage that WOULD be done if they also had the ability to access the >> inventory system AND the general accounting software. (even just the ability >> to partially close a ticket is dangerous) > > Why are you blaming the workers rather than the employers? Blame belongs on those who steal. I’ve experienced both employees and employers stealing. I’ve experienced restaurant servers manipulating the point of sale system to steal. I’ve experienced managers doing the same. In both cases, the control-checks that were in place caught them, but didn’t prevent them. So the access to functions was changed as a preventative measure and the control-checks were updated. A manager with access to hide evidence of, or alter transactions in the general ledger? That’s begging for trouble. I once caught a manager who stole cash. I was only able to catch him because of the control-check we had in place. Had he access to that control-check and been able to alter its record of our petty-cash flow, we’d have never been able to pin point who was responsible. Had we not been using the control properly (as I discovered in another unit) we’d have never even realized the cash was missing. > > Why do you think a piece of software can help if you are shitting on your > employees. > > Mike, is this what you expected as a response? Adrien appears to be a person > that trusts no-one. > > Welcome to the tacky politics of Trumpian merka :( > > >> As for interoperability, the devil is always in the details but I see three >> main hangups. First, any software should be able to import it’s own exports. > > Yes, import and export should work but doesn't. I'm not fussed because I > know how to make it happen anyway. I'm just not allowed to tell you how > because a senior gets upset if I say. I doubt seriously John, Geert, David or anyone else will be mad if you explain to users how to properly manage an export and re-import. (not that it matters much now, since this is to be possible with 3.0 anyway) > >> Second, any software with imports should be able to allow the user an easy >> way to map fields and save that mapping for future use. > > Not important, that is usually a one-off and gnc does that anyway. Somewhat. And I hope this will be improved with 3.0. And it isn’t a one-off if you have to repeatedly import data. You’d want to set the import mapping one time as long as it hasn’t changed. You wouldn’t want to have to re-map each time you import. > >> Third, importing and exporting should be possible to schedule or trigger >> without manual user intervention. (so apps can talk to each other reliably >> without lag) > > Wrong! I specifically do *not* want importing and exporting to happen > without me saying so. Maybe you don’t, and certainly you should always have such control. But others might want to automate some areas of data exchange. Gnucash never has to implement this, but there is a valid use case for it. > >> I think 3.0 is going to partially address the first and second case. I don’t >> think the third is contemplated yet. The third is also dangerous for >> accounting so it should be very carefully implemented and certainly not a >> default condition. > > The third is sufficiently dangerous that I say NO. > > -- > Wm > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Planned MAJOR OUTAGE: Thursday 08th of February, 17:00 - 19:00 UTC
> On Feb 14, 2018, at 8:10 AM, Derek Atkins wrote: > > John Ralls writes: > >> I think the only thing there that will impact us is bugzilla. > > We should really start thinking about running our own BZ instance, > assuming we can get a DB Dump from GNOME. Maybe, but not until you’re into your new house. ;-) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Planned MAJOR OUTAGE: Thursday 08th of February, 17:00 - 19:00 UTC
It might take that long to get a db dump. ;-) But yes, you're right. -derek Sent using my mobile device. Please excuse any typos. On February 14, 2018 8:37:55 PM John Ralls wrote: On Feb 14, 2018, at 8:10 AM, Derek Atkins wrote: John Ralls writes: I think the only thing there that will impact us is bugzilla. We should really start thinking about running our own BZ instance, assuming we can get a DB Dump from GNOME. Maybe, but not until you’re into your new house. ;-) Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Planned MAJOR OUTAGE: Thursday 08th of February, 17:00 - 19:00 UTC
The thing is that a db dump will be a snapshot, so what we want to do is have BZ set up and ready to go on code, then get the Gnome bug team to turn off our BZ instance there and send us a dump that we can immediately load and then turn on our instance. We may want to pre-process the db dump to have sequential numbers. It’s something to think about. We also need to think about what BZ we’re going to use. Gnome forked BZ somewhere around version 3 and have made some modifications to suit their needs. We can take that fork and tweak it for our use (just an e.g. it wouldn’t make a lot of sense for us to have “Not Gnome” as a reason for resolving a bug) or we can get the current Mozilla BZ and use that, recognizing that we’ll probably need to tweak the db dump from Gnome to get it to load. So a modification to my lead: We need two dumps, a preliminary one to test with while we get our BZ set up and then a final one that turns off the Gnome instance. We might want to look at what else is available before settling on BZ. In addition to you getting your new house done, Geert, Frank, and I need to focus on getting GC3 out the door, so let’s defer further discussion of this until later this spring. There are no signs on the Gnome lists that BZ is going to be shut down any time soon, so there’s no real rush. Regards, John Ralls > On Feb 14, 2018, at 5:41 PM, Derek Atkins wrote: > > It might take that long to get a db dump. ;-) > But yes, you're right. > > -derek > Sent using my mobile device. Please excuse any typos. > > > > On February 14, 2018 8:37:55 PM John Ralls wrote: > >> >> >>> On Feb 14, 2018, at 8:10 AM, Derek Atkins wrote: >>> >>> John Ralls writes: >>> I think the only thing there that will impact us is bugzilla. >>> >>> We should really start thinking about running our own BZ instance, >>> assuming we can get a DB Dump from GNOME. >> >> Maybe, but not until you’re into your new house. ;-) >> >> Regards, >> John Ralls >> >> ___ >> gnucash-devel mailing list >> gnucash-devel@gnucash.org >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
