Hi,
On Sun, May 22, 2016 at 3:26 PM, Marjanw <pr002...@proximus.be> wrote:
> Hi Erik,
>
> On 2016-05-20 22:55, Erik Huelsmann wrote:
> > Hi Marjan,
> >
> > On Fri, May 20, 2016 at 5:02 PM, Marjanw <pr002...@proximus.be <mailto:
> pr002...@proximus.be>> wrote:
> >
> > Hi all,
> >
> > I think this discussion demonstrates there are different types of
> users.
> > We simply have to admit that!
> >
> >
> > Absolutely! I'm the last one to deny so. However, there are some things
> that can't be left to the
> > user as a choice: if people want to use their browsers with unsafe
> encryption, Google and Firefox
> > now won't let them anymore. The same applies to GPG which will soon be
> removing (or maybe has
> > already removed) support for known-insecure algorithms. Shooting oneself
> in the foot that way isn't
> > supported any more.
>
> Comparing a different practices to insecure algorithms is inappropriate.
> Nobody wants insecure encryption. (Well goverments do actually.)
> Different workflows may be necessary however to accommodate our users.
>
First, I agree with your contrast. Of course the algorithms (and the
security of those) have to come first. Then we have to figure out the
appropriate workflows. The problems here are actually all algorithm
issues. So "delete" or "edit" is the wrong approach. That doesn't mean we
cannot support the same workflows though (i.e. same approach for data
entry). The question is, "How important is it that the transaction REALLY
IS edited in place?" If the workflow is what is important, then the answer
to that question is "not so much" and the workflows can be supported.
As for the algorithm issues, here is the basic issue: we have an
accounting program. We expect it to output correct numbers, at least to an
extent accountants agree is accepted. This means we have some
limitations. In particular we have to avoid putting ourselves in a
position where we cannot give such answers because no answer is accepted.
One thing to understand here is that in some areas there is some
disagreement over acceptable practices (this is particularly true as we try
to meet the needs of businesses around the world) but if we stray outside
of acceptable practices (according to the profession) we can run into
accounting questions which have no accepted answers by accountants.
Overwriting and deleting transactions are practices which raise a bunch of
these questions. If you can't get acceptable answers from our software,
you have to work it out separately, and the chance of making mistakes goes
way up. If there is sufficient interest, I will go into these on your
other thread.
So this is one case where it is really highly advisable that we don't offer
this choice as such. However that doesn't mean we cannot offer equivalent
workflows. If possible I would like to focus the discussion on how to meet
workflow needs rather than what people want to happen behind the scenes.
>
> Not all of us are working for big multi-national companies.
> I don't know if there have ever been done an inquiry about usage of LSMB.
> If not it might be a good idea to organize such an inquiry.
>
I agree. That's one reason why we allow separation of duties to be
disabled.
>
> I guess LSMB is very often used for small firms.
> In my personal case I don't need GAAP at all.
> In Belgium if your revenues are less than 500.000 Euro it isn't even
> required
> to use a double accounting system!
> So demands may vary a lot.
>
Agreed with the variation. That's one reason why we try to make LSMB
customizeable. This is particularly important when there are regulatory
compliance or tax reporting needs (one of the reasons Peeter is asking for
edit capabilities -- again we can probably find a solution that works well
for everyone).
>
> >
> > My point: The functionalities we offer should be in line with the
> requirements that our users have
> > *as well as* the requirements that our users *should* have (e.g.
> universal legal and auditing
> > requirements). Our users are very often not accounting professionals and
> like the encryption
> > software users (who 99% will not be algorithm savvy), I think it's our
> role to help them not to
> > shoot themselves in the foot.
> >
> > Open Source software is all about freedom.
> >
> >
> > True. It's about the freedom to own your own software and modify it to
> suit your needs. The
> > LedgerSMB project whole-heartily supports that concept: we're giving -
> free as in speech *and* free
> > as in beer - to the community the software that volunteers have invested
> years of their life in -
> > mostly without compensation of any kind (i.e. without being paid for it
> by anyone).
>
> I acknowledge that!
> It's great that there are people in this world, which volunteer without
> strings
> to make our world better. Thank you!
>
> >
> > Freedom is an important drive for many of us to use Open Source
> software.
> >
> > Yup. Same here. Although I can't help the feeling that for many people
> the fact that a lot of FOSS
> > is 'free as in beer' remains an important property of the software.
> >
> > Restricting freedom will make users unhappy.
> >
> > Maybe. Can you say in what way LedgerSMB's development team doesn't
> abide by the Open Source
> > movement's ideas according to your opinion?
> >
> > In the end they will vote by their feet.
> >
> > Why? They got the freedom they were promised! They can even edit the
> sources themselves which will
> > allow them to do the foot-shooting, after all?
>
> Do you want this discussion to end in a fork?
>
Ok, so I think it is helpful to go over the vision of freedom I worked on
building with LedgerSMB. Freedom has been at the center of the project
since we forked from SQL-Ledger.
Something like this poses serious problems I don't see the LSMB project
taking on. For those of us who remember why we decided to stop supporting
editing and deleting transactions (and this was something extensively
discussed on this list somewhere around 2008), the opportunity to go back
there really isn't appealing. I am however happy to give guidance as to
the accounting problems that result. I don't think a one-size-fits-many
solution is possible here. There are too many really nasty corner cases
and these mean that it is usually best for things to be figured out between
the users and their accountants first.
LedgerSMB is being re-engineered as a series of stacked platforms. The
idea is that components should be stable but workflows should be easy to
implement on top of that stability. I usually find that agility in
development is easiest when it sits on top of a series of stable
components. That is what we are trying to accomplish. Yes, there is room
for users to customize the software or pay someone to do so. That is a
part of our freedom model.
Additionally I would add that some things really should be customizations.
Businesses want to support workflows they see as competitive advantages.
Others want things that are not generally applicable. There is nothing
wrong with that. Enabling this approach gives users the ability to build
the software around their business rather than the other way.
>
> >
> > So I think the only satisfactory solution will be to offer our users
> the freedom to choose.
> > If we have users, which feel they need some form of editing,
> deleting/redoing a transaction,
> > and this is technically possible, we should not restrict them from
> doing that.
> >
> >
> > I disagree for several reasons:
> >
> > * encryption software won't offer you the option to use insecure
> algorithms and we should not
> > offer methods that are legally or ethically banned
> Not appropriate here, see above.
>
Workflow and accounting numbers calculations are separable. I think
encryption *is* a good parallel to the calculation algorithms. Of course
workflow (and how you use encryption) are entirely a separate matter!
>
> > * in this specific case, there's really no easy way to correctly
> implement this in our current
> > code base
>
> Ok, users will understand this.
> There may be technical arguments why it is not possible to implement a
> requested function (now).
>
The problem goes beyond technical. In a FIFO inventory system, there is no
agreement on what deleting an invoice *means* for inventory valuation
because the agreed answer by accountants is "don't do that." We can't
provide acceptable answers if accountants don't accept the path to get
there.
>
> > * more options bear a maintenance cost to the development team *and*
> make the program harder to
> > configure and understand for users -- we should not think lightly of
> introducing new options
>
> Sure, I gree. We should think thoroughly before adding new functionality.
>
Also I would add that if we allow this anywhere, then it becomes impossible
to know that it was never allowed. And since this affects things like
inventory valuation, that erodes trust in the numbers.
I think there are two things being discussed.
The first is "Can I use an edit workflow on transactions?" Yes we can
build that. "Can I find a way to retrieve only non-voided transactions?"
Yes we can build that. I think that is the important discussion on the
user side.
Then there is "Can I edit a transaction in place?" and "Can I delete a
transaction from the database?" That is a different question with a
different set of considerations that go into the answer.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
