On Thu, Jun 21, 2012 at 7:09 PM, Peter Dolding <[email protected]> wrote:
> Chris Travers <[email protected]>
> > 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.
>
Ok, I see two problems with a lot of this. The first is that while
something like sales tax is relatively straight-forward, a lot of things do
depend on implementation, and there may be nuance there. For example, I
don't really know what the effect of HST on the question of whether a
muffin sold in a coffee shop in Toronto (Ontario, Canada), and if HST
hasn't greatly affected the rules there, I wouldn't want to be in charge of
making sure my interpretation of the rules were correct.
As I say I don't know what the current state is after HST was implemented,
but before then, the tax rate depended on what else the customer bought.
As I understand the previous rules:
If the muffin is not individually wrapped and you buy fewer than six then
it is taxable if and only if the subtotal of all prepared foods and
beverages is greater than $4 CAD. On the other hand if it is individually
wrapped then it is always taxable unless another prepared food or beverage
is purchased and the subtotal is less than $4 CAD.
I see this as a classic example of where someone on the ground really must
address the sales tax directly, or at least work with us to do so. I am
not sticking my neck out there interpreting rules like that.
> >
> > 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.
>
Certainly with sales tax there is a most common scenario, which we can
support internationally. This is that for a given customer and good
purchased the tax rate is constant. Note there are an increasing number
of places where this breaks down (the US for example) and so we have to
decide when and where to make adjustments to what's supported as part of
the overall offering and what's a local party's responsibility.
> >
> > 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.
>
The concern I have is that when you look at sales tax reporting
requirements in states in the US and you compare to state income tax
reporting requirements, it's pretty clear that the sales tax requirements
are more complex and more burdensome, and that it is becoming more complex
faster than any other tax form around. Sales taxes don't have to be
simple, and I see a number of reasons why they might tend towards great
complexity and variety.
>
> 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.
>
Sales tax in a POS tends to be often, in the US at least (I don't know
elsewhere) the least complex aspect. For example, in most states in the
US, sales tax only becomes complex once you start delivering things to
customers. Of course in Ontario, Canada, at least prior to the HST
compromise (I don't know the situation currently) POS sales taxes tended
towards great complexity.
>
> Really to work out what has to be modules what has to be common.
> Requires making a list of the rules and regulations globally.
>
There are also questions of interpretation and nuance and there's no reason
to think that the same general requirements in two places won't have corner
cases where the interpretation is different. So a list of regulations only
gets you so far.
>
> 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.
>
Unfortunately, sales tax is highly regional. Also prior to HST, the way it
worked in Quebec was that the national sales taxes were taxed by the
province. The requirements were such that we decided to handle this in
LedgerSMB, but we decided not to handle the Ontario coffee shop scenario
directly (and not getting into rules in Ontario about sales tax and
coupons, where the effect on sales tax is dependent on who issued the
coupon).
I think that the best we can do here is to document the situations which we
handle natively and provide hooks for other cases not supported. We
provide several kinds of hooks in 1.3 for this.
>
> 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.
>
Again, I think that this is a case where we need to be working with people
on the ground regarding understanding what the tests are and getting listed.
That doesn't mean we don't have a set of lists. It does mean those lists
are driven by folks on the ground. It also means that we have to work with
people on the ground, providing help and support in order to make this
happen. I think that as we show we can do this, more regions will end up
with partners who know their stuff and can help in these areas.
>
> To be used accountants and small business have to know the project
> exists. Unfortunately being just on source-forge does not work for
> that.
>
Agreed there.
>
> 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.
>
Agreed there also.
>
> 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.
>
Again, I would like to see this sort of thing be local partner driven
rather than centrally managed. There are huge problems in interpreting
rules in complex legal frameworks, and the only way I think we can expect
these to be both maintained and accurate is with boots on the ground, so to
speak.
Best Wishes,
Chris Travers
>
> Peter Dolding
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
