On 13/02/2018 15:30, Adrien Monteleone wrote:
I agree completely on the separation point, especially with regard to controls.
If you agree on that you are an idiot, Mike's POV is (if I understand
correctly over a period of time) mainly a charitable one.
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?
Why do you think a piece of software can help if you are shitting on
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.
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.
Third, importing and exporting should be possible to schedule or trigger
without manual user intervention. (so apps can talk to each other reliably
Wrong! I specifically do *not* want importing and exporting to happen
without me saying so.
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
The third is sufficiently dangerous that I say NO.
gnucash-devel mailing list