> On Feb 13, 2018, at 8:49 PM, Wm via gnucash-devel <firstname.lastname@example.org>
> On 13/02/2018 15:30, Adrien Monteleone wrote:
>> I agree completely on the separation point, especially with regard to
> 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
> 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.
> gnucash-devel mailing list
gnucash-devel mailing list