gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]