Re: [Fwd: Re: payroll]

Re: [Fwd: Re: payroll]

> Are the rules released in a structured format? If so could an
> xml-described version of them not be 'loaded into' the payroll system?
> A group of generous tax lawyers could scrutinise the release and an
> official versions could be released?

Yes, but this is a separate issue.

One thing is the complexity of many jurisdictions with changing rules.

The separate one that I'm talking about is the "global" nature of the
rules: figuring out the right transaction to enter is not just a
matter of looking at "local" information, for at least some important
sets of rules.

Re: [Fwd: Re: payroll]

> For this kind of problem requiring continuous expert review and updates,
> I have always envisioned an open-source engine with paid-for data.

Please remember, this is a free software project. If people want to
have non-free software (both programs and data are software), then
that's up to them, but it shouldn't be our job or business to
encourage them.

> The tax lawyers would offer the xml-described data for sale on a
> subscription basis, say quarterly updates.

This would be extraordinary. Normally, legal advice is free (libre);
that is, your lawyer gives you advice or explains the law to you, and
you are free to repeat his advice or explanation to whoever you like.

Let's foster that model if we can.

> It would be nice if this would happen for personal tax software
> also, but protecting copyright of the xml data would be easier for
> businesses.

I don't think businesses are helped by being forced to use restricted
information. Businesses would be much more helped by a free software
product.

> Updates could include a digital signed serial number so
> that copyright violations could be detected.

I want to urge very strongly that we not include *any* feature like
this. Geez, are we now cops on behalf of the software-hoarders too?

Re: [Fwd: Re: payroll]

On Wed, 2005-05-25 at 19:07 -0700, Thomas Bushnell BSG wrote:
> "Stuart D. Gathman" <[hidden email]> writes:
> > For this kind of problem requiring continuous expert review and updates,
> > I have always envisioned an open-source engine with paid-for data.
> Please remember, this is a free software project. If people want to
> have non-free software (both programs and data are software), then
> that's up to them, but it shouldn't be our job or business to
> encourage them.

Yes and no. Gnucash shouldn't be requiring it, but by the same token,
shouldn't be restricting it either.

I don't see anything in the basic suggestion that is incompatible with
free software. If someone wants to provide the data free, and keep it
maintained, up to date and guaranteed accurate, for free - well that's a
bonus to people in their jurisdiction - assuming they trust it to be
maintained, up to date, and accurate.
I had rather assumed that the data files would probably be paid-for (at
least for people who are taking this seriously - who are running
businesses and really paying people money). Why? Because as a business
owner and manager, I want to know:
a) that I will get updates when updates are required, not just when
someone gets around to it; and
b) that the data is accurate, and isn't going to get me into trouble
with the tax office for failing to do the right thing.

Its not gnucashs business to make it exclusive (in either direction). If
you want the software to be used, be realistic, not restrictive.

> > The tax lawyers would offer the xml-described data for sale on a
> > subscription basis, say quarterly updates.
> This would be extraordinary. Normally, legal advice is free (libre);
> that is, your lawyer gives you advice or explains the law to you, and
> you are free to repeat his advice or explanation to whoever you like.

I don't see how that is relevant in this case, since what you are paying
for is the update service, not advice. And leaving quite aside the
issues I have with your statement as it stands.

> I don't think businesses are helped by being forced to use restricted
> information. Businesses would be much more helped by a free software
> product.

Sure. If they could be assured that the accurate was accurate, etc. as
above. Paying for it gives a certain degree of assurance.

> > Updates could include a digital signed serial number so
> > that copyright violations could be detected.
> I want to urge very strongly that we not include *any* feature like
> this. Geez, are we now cops on behalf of the software-hoarders too?

On this point, I will agree with you wholeheartedly. Gnucash should not
have this sort of functionality. That's not to say that the data file
cannot have such a thing, just that gnucash has no role to play in
using/verifying that number - although if someone produces custom
reports that somehow use that number, that's up to them.

Re: [Fwd: Re: payroll]

>> I don't think businesses are helped by being forced to use restricted
>> information. Businesses would be much more helped by a free software
>> product.
>
> Sure. If they could be assured that the accurate was accurate, etc. as
> above. Paying for it gives a certain degree of assurance.

Well, those who think so can certainly shell out their money. I have
found that libre software gives me more assurance than commercial;
that support help from friends is more reliable than that I pay for;
and so forth.

Re: [Fwd: Re: payroll]

Thomas Bushnell BSG wrote:

> Conrad Canterford <[hidden email]> writes:
>
>
>>>I don't think businesses are helped by being forced to use restricted
>>>information. Businesses would be much more helped by a free software
>>>product.
>>
>>Sure. If they could be assured that the accurate was accurate, etc. as
>>above. Paying for it gives a certain degree of assurance.
>
>
> Well, those who think so can certainly shell out their money. I have
> found that libre software gives me more assurance than commercial;
> that support help from friends is more reliable than that I pay for;
> and so forth.
>

I can second that as I've watched quickbooks incorrectly compute taxes
by a significant margin and had friends work out spreadsheets that "just
work"

Re: [Fwd: Re: payroll]

On Thu, 2005-05-26 at 09:01 -0700, Andrew Sackville-West wrote:
> Thomas Bushnell BSG wrote:
> > Well, those who think so can certainly shell out their money. I have
> > found that libre software gives me more assurance than commercial;
> > that support help from friends is more reliable than that I pay for;
> > and so forth.
> I can second that as I've watched quickbooks incorrectly compute taxes
> by a significant margin and had friends work out spreadsheets that "just
> work"

Fine. If that works for you, and you're happy with that, great. All I'm
saying is that that is not the case for everyone, and we should be open
to the prospect of paid-for datafiles while at the same time not
requiring them.

In .au there are penalties for getting it wrong (hence my concern that
the data files be accurate), even though in practice the tax office can
claw back any shortfall through the tax return process.

Anyway. I think we're basically in agreement with that.

By the way, the formula types listed do basically match my recollection
of the .au system. If you're doing things strictly accurate, the
formulas are a bit more complicated then that (from memory) but in
practice they match up with this. I'll dig out the appropriate stuff at
some point and double check my memory though, as it has been a few years
since I looked at this.

Note that (as mentioned by other people) there may be a requirement that
the tax amount be rounded to the nearest whole $ amount or (in .au) the
next lowest whole $ amount.

With the interface, I was envisaging something like the standard
register, with perhaps a few extra fields. Not sure how well that will
integrate with g2 as I haven't looked at g2. Also not sure that we'll be
able to meaningfully include that much extra information in the register
format without making it really ugly. But its a thought anyway.

Re: [Fwd: Re: payroll]

On Fri, 27 May 2005, Conrad Canterford wrote:

> In .au there are penalties for getting it wrong (hence my concern that
> the data files be accurate), even though in practice the tax office can
> claw back any shortfall through the tax return process.

I agree with the suggestion that the government *ought* to publish
machine readable tax data at no charge. Establishing an open format is a
necessary first step in that direction. Our customers are US importers,
and the US gov publishes quite a bit of machine readable data
necessary to properly file entries. That trend needs to grow, if
they expect compliance with ever more complex tax codes.

Re: [Fwd: Re: payroll]

On Thu, 2005-26-05 at 18:49 -0400, Stuart D. Gathman wrote:

> On Fri, 27 May 2005, Conrad Canterford wrote:
>
> > In .au there are penalties for getting it wrong (hence my concern that
> > the data files be accurate), even though in practice the tax office can
> > claw back any shortfall through the tax return process.
>
> I agree with the suggestion that the government *ought* to publish
> machine readable tax data at no charge. Establishing an open format is a
> necessary first step in that direction. Our customers are US importers,
> and the US gov publishes quite a bit of machine readable data
> necessary to properly file entries. That trend needs to grow, if
> they expect compliance with ever more complex tax codes.
>

In Canada the government publishes their payroll tax info on cd with a
java app to compute the taxes,etc.. FOR FREE :) Unfortunately, it is
only for WindBlows and MAC. It seems to do just the basic calculations.
No storage of info other than initial config (Company name, # of pay
periods, etc). They are trying to get away from the printed versions
which cost more to produce and distribute.

I think that if we can get a decent payroll module together with a
straightforward config for the tax formulae that they may even supply
the updates (eventually, if enough users keep requesting it).
--
Brian <[hidden email]>