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
