> 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. > 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
