Re: Freedom; Re: migration to sql-ledger

Hi,

On Sun, May 22, 2016 at 3:26 PM, Marjanw <..hidden..> wrote:

Hi Erik,

On 2016-05-20 22:55, Erik Huelsmann wrote:
> Hi Marjan,
>
> On Fri, May 20, 2016 at 5:02 PM, Marjanw <..hidden.. <mailto:..hidden..>> 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