Wm, this is a GnuCash miallist, not a political forum. If there was any useful information in that last spate, I didn't even see it.
Liz, you have my permission to cut him off again. David C On Fri, Feb 16, 2018 at 9:17 AM, Wm via gnucash-devel < gnucash-devel@gnucash.org> wrote: > On 14/02/2018 18:07, Adrien Monteleone wrote: > >> >> On Feb 13, 2018, at 8:49 PM, Wm via gnucash-devel < >>> gnucash-devel@gnucash.org> 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. >> > > I reply as I feel fit > > >> 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 have been employed as one of them more than once. > > AT THIS POINT I POINT OUT > > you are out of your depth. > > You're addressing me in terms of words rather than facts. Grow up or get > a hash tag <-- and the associated despicable "I am a man and I need to > defend crap" > > 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. >> > > > That is interesting but completely out of the "Scope" of what gnc is > likely to do. > > >>> 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) >> > > Indeed, they are waiting for this discussion to go away. > > The answer is to write back using anything you like and check afterwards, > btw. Just don't tell anyone. The closer the db gets to normality the more > things like that work. > > > >>> 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. >> > > Only until you get it right, then you don't care. I have done hundreds of > imports, that is the nature of the beast. > > 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've never noticed one. New thread, I think. > > 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. >>> >> > _______________________________________________ > 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
