Re: [Fwd: Re: payroll]
On Wed, 2005-05-25 at 19:07 -0700, Thomas Bushnell BSG wrote: Stuart D. Gathman [EMAIL PROTECTED] 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. Conrad. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Re: payroll]
Conrad Canterford [EMAIL PROTECTED] 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. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Re: payroll]
Thomas Bushnell BSG wrote: Conrad Canterford [EMAIL PROTECTED] 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 A ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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. Conrad. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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. -- Stuart D. Gathman [EMAIL PROTECTED] Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 Confutatis maledictis, flamis acribus addictis - background song for a Microsoft sponsored Where do you want to go from here? commercial. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
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 [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[Fwd: Re: payroll]
[Sorry, Thomas, I meant to send this to the whole list] 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? Or am I just dreaming? Tom Thomas Bushnell BSG wrote: Derek Atkins [EMAIL PROTECTED] writes: But how do you handle something like the FICA witholding in the US? The witholding is 6.5% from the employee, 6.5% from the employer (i.e, it's a payroll tax that's above and beyond the gross pay, and must come from the employer).. But even worse, only the first $87,000 of taxable income is subject to FICA witholding. So the function needs to know how much have I paid this person this calendar year in order to properly compute FICA. A related global sort of question is the making of withheld tax payments. A payroll system needs to tell you how much and when to ship off to the feds and the state tax people. The formulas to compute this are complex, and depend on the total amount outstanding and the timing of various withholdings. This is also an area where the rules change regularly, and in which failure to get them right can incur very serious penalties. Thomas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Re: payroll]
On Wed, 25 May 2005, Tom Haskins-Vaughan wrote: 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? Or am I just dreaming? For this kind of problem requiring continuous expert review and updates, I have always envisioned an open-source engine with paid-for data. The tax lawyers would offer the xml-described data for sale on a subscription basis, say quarterly updates. The engine and format is open, so multiple firms can compete for the update business. 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. Updates could include a digital signed serial number so that copyright violations could be detected. -- Stuart D. Gathman [EMAIL PROTECTED] Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 Confutatis maledictis, flamis acribus addictis - background song for a Microsoft sponsored Where do you want to go from here? commercial. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Re: payroll]
Stuart D. Gathman [EMAIL PROTECTED] 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. 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? Thomas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
