[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: Billing/invoicing for GNUmed
From: |
Sebastian Hilbert |
Subject: |
Re: [Gnumed-devel] Re: Billing/invoicing for GNUmed |
Date: |
Mon, 7 Jun 2010 13:18:28 +0200 |
User-agent: |
KMail/1.13.3 (Linux/2.6.33-6-desktop; KDE/4.4.3; i686; ; ) |
Am Montag 07 Juni 2010, 12:05:07 schrieb Andreas Tille:
> On Mon, Jun 07, 2010 at 11:07:50AM +0200, Sebastian Hilbert wrote:
> > > $ apt-cache show sql-ledger
> > >
> > > I do not know about the difference of lx-office from sql-ledger, but
> > > sql-ledger packages exist (since several years).
> >
> > We will have to check that with regards to the following issues.
> >
> > Lx-Office was supposedly forked because it was not possible to adapt it
> > to German needs within the project.
>
> "not possible" - in IT this very frequently tranlates to: I'm not willing
> to, I'm not skilled enough, etc.
>
> > Lx-Office is targeted at German companies which implies that they have
> > possibly made the same mistake and it might not be usable outside
> > Germany.
>
> Relaying on a fork which was created because of reasons which are not
> fully clarified (I mean whether the authors are just not willing or are
> not motivated to change, whatever) is not really a good idea IMHO.
> Moreover it restricts the billing functionality of GNUmed to German
> users which is also not wanted in the end.
I do not have enough information on what exactly is the problem. But this
shines some light on it.
http://lwn.net/Articles/227283/
It is always the same. There is always one person who does not do what the
other people want. Whatever the reasons are the other people feel they cannot
move on unless they fork. So they fork. Most fork die. Seems like ledger-smb
and lx-office did not.
Anyway it might be worth the effort to write some emails but the longer a fork
exists the smaller the chance that they will come together as one.
Choice is not a bad thing.
>
> > Lx-Office has a German and and an English interface. Someone skilled
> > should check it from an accounting point of view.
>
> I have not even an idea what exactly accounting means
It means in Germany you have different taxes and whatnot. Same with health
related billing. There is no one fits all. If the code does not support
different countries a priori there is little you can do but fork. Once you
fork you decide if you do the same mistake which leads to results faster or if
you want to go the extra mile.
Same for GNUmed. If we just wanted to build a German billing system GNUmed
would have been completed long ago.
> - so I'm probably
> not the right person to investigate here. But if I would start my
> research I would probably try to dig for the discussion which was the
> root of the fork and read the arguing. Does it really sounds
> convincing? Is there any programming API which is the same for
> sql-ledger and lx-office which somehow might abstract the difference?
>
There is no real API I am aware of. sql-ledger and lx-office still share some
code so calling functions on the commandline is the same in principle. The
expressions to call may be different. The api can be gmBilling which would let
people implement their favourite ledger.
> I'm not very optimistic that lx-office will be packaged for Debian as a
> competing package to sql-ledger ...
Well it depends if lx-office is technicall superior or not. German users have
no fun with sql-ledger I would assume. I am not sure the other way around.
You have a point here. Since ledger-smb is a fork of sql-ledger as well
chances are good that gmBilling can support slqledger, ledger-smb and lx-
office.
I have used Lx-office for a small business for some years. It is not too hard
to install from source. However since a package exists it might be worth
checking out how much work is involved to include it into Debian
Best regards,
Sebastian
Re: [Gnumed-devel] Billing/invoicing for GNUmed, Sebastian Hilbert, 2010/06/08