Re: Add wiki page for Government requirements around the world and possibly build a testsuite from them.

[Peter Dolding <..hidden..>]

Chris Travers <..hidden..>
> The problem which no single business can address as such is the fact
> that all these different jurisdictions  are, well, different.  They
> change their regulations on different schedules, the regulations may
> be somewhat nuanced, and so forth.  This means that this is not a
> problem which is well suited to a single player in the industry to
> solve, and it really requires local voices who know the regulations
> both in theory and practice, and can act as a voice helping the
> community figure out what we need to do to meet the regulatory
> requirements.

This is another reason for having a list.  Australia has a very fixed
schedules.  Tax system changes between june 30 and july1 at midnight.
 No official tax change can be applied at any other time in the year.
Information about proposed changes are released before that and is
basically locked in 2 months before the date so software can change.
Also that gives you 12 months to implement the change fully for
anything other than bas reporting.  Business activity reporting is 1
month for large companies 3 months for medium companies and 12 months
for small companies.  Yes those 3 months reports are all at exactly
the same time.  So small business you have 12 months to implment  mid
range business you have 3 months to implement.    So yes there is a
bias to get large businesses to chip in.   Since they will require it
first.  This should make getting partners that can pay simpler.
>
> Also a lot of regulatory compliance work is a bit difficult to pay for
> in a standard pay-for-development open source model since it leads to
> one person paying for compliance for everyone else, over and over.  I
> think paying for it will require a local party offering support
> subscriptions.  (I can partner with you on these if you need
> development help etc).

True but there is a catch here.  There is a chance that between
regions there are common tests.  Without a list of the regulation
requirements those common tests cannot be found.

Not like Australia sales tax system is 100 percent unique.
>
> I think this is one thing we are both trying to address.  I would like
> to see however the idea that we create a place for local players in
> helping get this through.
>
> So I guess I would turn the proposal on its head and suggest:
>
> 1)  We look at seeing what we need to do to pass these tests if we
> don't do so already
> 2)  We look into the registration process
> 3)  We look for local partners in Australia who can help with things
> like payroll regulations.
>
> Looking through the set of tests:
>
> 1)  We don't currently automate a capital gains reporting, or AIIR reporting.
> 2)  We don't try to handle franked dividends
> 3)  The sales tax scenarios would apply
> 4)  The income tax withholding may be necessary as we get further.
> 5)  Some of the other reporting stuff is not handled yet but would be
> an area where a local partner might have a role in getting that going.
>
Areas that package don't handle at all that is something a local
partner can deal with by adding extension or other solution to cope
with.  So reporting bits missing  or capital gains reporting or AIIR
reporting or franked dividends these all can possible go to partner.
There is a catch.  There must be a safe way for partners to plug this
stuff in next to other partners plugins doing the same thing but
configured for different region.  The night mare of multi regional
accounting.  So if I am operating in Australia and NZ I would have to
report to both tax departments.

Items like sales tax in the pos part kinda have to work exactly right.
 Not something a partner should be attempting to fix.  Areas you do
like sales tax you might have to provide a interface that is clean for
partners to add location conditions and adjustments for current rules
in there area.  Remember big catch here is not all companies operate
in one country.  So the partners need to be able to apply there
regional alterations without altering the core applications code and
be able to operate along side each other without stomping on each
other.

Really to work out what has to be modules what has to be common.
Requires making a list of the rules and regulations globally.

Basically there needs to be a map.  So we know what functionality is
region particular and what functionality is truly generic.  Regional
particular stuff mixed into generic cause lot of pain.

John Hasler
> I run a business in Wisconsin, USA.  The tax authorities (state and
> federal) I deal with do not interest themselves at all in what
> accounting software I use.  They merely require that I "keep records".
> This was also the case in Minnesota and Michigan when I did business
> there.
This is one of the reasons we need a list.  Yes the list could include
an area mapping out all the places without government regulation as
well and possible work out what is core functionality.  Since these
are areas the project could go after for developers and users now.
Like possible doing simple thing like contacting http://ntaa.com.au/
equal in those countries and areas.  And if we knew it matched
Australia we could go after ntaa and other accountants boards to get
presence known.  Yes its even possible at times to demo new software
at there conferences for free.  So we are not talking large expenses
to advertise.  There is most likely other bodies around the world the
project is not providing notice about itself to that its ready to be
used by.

To be used accountants and small business have to know the project
exists.  Unfortunately being just on source-forge does not work for
that.

This is one of the big problems accountancy software works the other
way.  To get into the market you program have to match the functional
requirements of that area.  So you need start up investment but once
its started in a market you will be able to get on going support
payments.

This is why the project needs a map of what the regulation frameworks
look like.  Because if one year you match a requirements in an area
that might be enough to kick start partners in that area to maintain
it so expanding developers working on the project.    You can only
take advantage of that if you know you matched that year.

Information is power and the current problem is that the information
about accountany software requirements is spread to to four corners of
the earth.

I am very suspect that a lot of regulation requirements world wide
will be just minor reinventing wheel over and over again.  Most
governments are not what you call bright when it comes to tax law.

Peter Dolding