Software developers forums - top comments

As the manager of a young

jethrocarr — Wed, 09 Jun 2010 02:47:58 +0000

As the manager of a young software development company I would very much like to see a documented API based off an open standard (eg SOAP, REST, XML) which is avaliable to any company to use for communiticating with IRD.

New Zealand has companies ranging from large corporates developing accounting packages down to small one or two people development houses working on ecommerce systems and lightweight accounts applications.

It is important to be fair to both types of companies, making the API available to any company along with public documentation is the best way to do this.

From what I can tell so far reading this website, it seems that this is the way that IRD is planning to proceed, if so, then it sounds fantastic and I look forwards to seeing how this progresses.

-- Jethro Carr (jethro.carr@amberdms.com)

Sandbox There should be a

barnaclebarnes — Wed, 09 Jun 2010 03:27:32 +0000

Sandbox

There should be a sand boxed environment for testing that is open for developers to use.

The 3am Test

The API/service (at least the sandbox) should be available to start using at any time with no authorisation. In this way developers can get started on their own, develop their software and do all of the testing without having to talk to anyone. The more barriers you put up the less innovative services will appear.

Documentation

Good documentation with code examples in a number of languages (C#, Ruby, PHP, Python) is a must. Providing libraries that can be downloaded, are open source and hosted in shared environment such as Github will really help drive the developer ecosystem forward.

And if you want decent comments allow more that 1000 characters ;-)

I work with Acclipse, who

Stuart Bale — Sun, 20 Jun 2010 23:10:45 +0000

I work with Acclipse, who provide Income Tax preparation and management software to NZ Tax Agents.

Part of Acclipse Tax retrieves 'statement' data for tax entities from the IRD Portal that Tax Agents regularly use. Those tax agents using Acclipse Tax find this a big time saver and convenience, as the information they need is at their finger tips, and we are able to integrate the data directly into their workflow.

There would be some distinct benefits if this data was accessible in a more efficient method than we are using today, such as a web service.

Stuart

There is some need for a

barnaclebarnes — Wed, 09 Jun 2010 03:13:17 +0000

There is some need for a system that allows access to the IRD's system. We want to access several government systems and pull data in via API's. Ideally we would use standards such as oAuth to let users authenticate and give access to various data. As a start we would like:

GST and other filing dates for the company
Filing History
Payment history

Is this the kind of information you were thinking of?

I think this is a very good

flea — Sun, 27 Jun 2010 03:59:47 +0000

I think this is a very good idea as long as the make up of the group is balanced between technical, userabilty and market expertise. I also think it is important that this group is does not act unilaterally but provides a co-ordination point for wider discussions.

My company would have no

flea — Sun, 27 Jun 2010 02:20:48 +0000

My company would have no issue with developing software that provides increased tax functionality and being able to communicate directly with IRD. However we do have concerns regarding where the liability would lie if incorrect tax information ends up being filed with IRD. There is always a fine line between providing software that meets legislative requirements while providing enough flexibility for the employer to be able to manage their own employees - currently the employer accepts they are ultimately liable for the information provided to IRD.

If by providing more tax functionality in the software, the employer becomes unable to control or override the information, they will surely then expect the liability to lie with the software developer but as a developer we would not be comfortable with taking on the liability of any employer that uses our software.

I agree with the sentiment

matthewhaigh — Wed, 09 Jun 2010 22:20:58 +0000

I agree with the sentiment here - good observations guys - lets have an API - hopefully RESTful with authentication using OAuth or something similar. I would like to understand how the igovt identification service could be used with this service.

I note some disagreement from the existing comments - if you disagree with this - would really like to hear your opinion - what are we missing from this discussion?

Noting the moves of the Australian Government about Standard Business Reporting (SBR) - of which NZ has signed up too - I assume that the XBRL mechanism will be implemented - to allow filing of returns and other information to a 'government gateway'. If this was the case - I would like to see some information on the data representation - not just the DTD - but how the IRD and government agencies will like to see this information represented and interpreted.

I agree with Jethro. We need

barnaclebarnes — Wed, 09 Jun 2010 03:26:39 +0000

I agree with Jethro. We need access to the systems via easy to use (RESTful web services please) interfaces. IRD should not partner with large software providers exclusively as a first step as their needs will vary from some of the smaller players.

The services should:

RESTful Web Services

The services should support REST based interfaces. REST has won the web API wars and is the easiest for people to pick up.

Authentication

Authentication should be via open standards such as oAuth unless there is a very good reason to choose another standard. By choosing an open standard developers can get up and running quickly with very little effort using a number of existing libraries. Even if you require something more for 'write' access to peoples records you should have a simple interface for read only data.

cont...

There's also the opportunity

jethrocarr — Wed, 09 Jun 2010 04:32:20 +0000

There's also the opportunity to simplify PAYE a lot more by moving some of the processing and calculating to IRD's systems so that an application can submit information for an employee's salary and have IRD return back information on how much tax is owed.

-- Jethro Carr (jethro.carr@amberdms.com)

Thanks for the point on the

Moderator — Wed, 09 Jun 2010 03:33:00 +0000

Thanks for the point on the character limit. We've upped it from 1,000 to 5,000.

Communication, collaboration

100000596760411@facebook — Fri, 23 Jul 2010 00:22:26 +0000

Communication, collaboration and communication.

Well documented API, although standards based services would be ideal anything is better than nothing.

The most successful web 2.0 platforms provide a powerful API that allows developers to intergrate third party applications and extend the base platforms in ways the creators never imagined.

The IR has the opportunity to leverage the power of the accounting software developer community to create applications for the public / business community.

There are two key factors in making this a success:
1) Working closely with the software development community so they can provide great applications that make people want to move online. This means communication, communication and collaboration. The developer community has been excited about possibilities integrating with the IR systems holds for decades. Let’s make these dreams possible!

2)Change management for your customers . Much of the population will embrace this change, ensure the ones that don’t are given enough attention. Listen to their concerns and talk to the development community about how we can tackle them together.

The SDLU conferences are great, lets make it more of a two way dialog. We know your clients (especially accountants) and how they work and file. Let us share that knowledge with you and revolutionise how the IR communicates with clients!

We have successfully been

100000596760411@facebook — Fri, 23 Jul 2010 00:17:58 +0000

We have successfully been developing complex tax functionality into our software for many years. As mentioned earlier there are risks, however these are manageable. As Stuart has said the missing link is the ability to allow these applications to interact with the information on the IR data stores.

Some kind of quality control over tax logic is required so providing developers with test data sets and certification is a good idea.

Here is an idea... Why can't

Concrete Sam — Wed, 07 Jul 2010 10:35:54 +0000

Here is an idea... Why can't our eftpos cards contain a memory chip that stores transaction data ie the receipts. The data could be uploaded and sorted by your computer. You could know how much tax you need to put away in real time, no more faded receipts from sitting in the car on a hot day, no more paying $60 an hour to have the accountants secretary sort through things - The benefits are on going and I believe a system like it is inevitable. NZ is probably the best positioned country in the world to come up with something like this, and if we got it going first I would say it could turn into a massive international earner for us.....

Any form of quality

flea — Sun, 27 Jun 2010 02:57:25 +0000

Any form of quality management of this nature always creates additional workload for the developer as it needs to be built into their software development lifecycle process and I question the need for this type of control. Does being a "registered developer" or having "IRD approved" attached to your product really add value to the customer? Sure it might increase customer confidence for buying products sold off the shelf via retail outlets or online, but as for the developers that don't use those channels for their sales is it really of any benefit? As a developer of many years we are confident in our own ability to develop software that meets legislative requirements without the need to be certified/endorsed – fundamentally if our software was not meeting the requirements we would not have any customers.

If it is deemed necessary to have a quality management system then I think the Australian Tax Office system works fairly well. It breaks down the various areas of compliance (as Jethrocarr has suggested) and as a developer you can register your product, after testing your product using the test scenarios provided by the ATO, for whichever areas are relevant to your product.
Under the ATO model you don't normally register a specific version of your product and as a developer it is your responsibility to ensure that once you have registered your product any subsequent versions/updates remain compliant (always using the latest published test scenario). It is also the developer's responsibility to ensure any new/updated test scenarios published by the ATO are tested against their product.

VERSION SPECIFIC? Will

jethrocarr — Wed, 09 Jun 2010 02:59:55 +0000

VERSION SPECIFIC?

Will certification be against specific software versions? There are a lot of open source and web-based applications that have very fast paced development and don't conform to the traditional boxed release cycle.

Only certifiying against a specific version wouldn't work very well with these sorts of applications since the certification would always lag behind the current release.

LEVEL OF COMPLIANCE?

An application like an ecommerce website may only need to implement a few features in comparision to an application like an accounting package which may need to implement almost all of them.

It would be good to have different levels of compliance, or certification for compliance with specific f

Considering that 30% of

flea — Sun, 27 Jun 2010 03:38:55 +0000

Considering that 30% of employers already file electronically, covering 80% of employees, that implies to me that the vast majority of those employers are already using software (which already provides tax compliance functionality). The remaining 70% of employers only account for 20% of employees and that implies to me each employer only has few employees and currently has no requirement for payroll software.

The tax compliance side of payroll is relatively easy compared to the Holiday Act requirements and therefore unless a small employer requires software to assist them with the holiday side of things why would they bother paying for payroll software when they can manage a couple of employees very easily manually (using printed tax tables or IRD calculators) and still file their EMS electronically.

So while I am sure employers who already use payroll software would appreciate their software having enhanced tax compliance functionality (i.e. direct access to IRD) I doubt very much that that this type of enhanced functionality would create any significant new market for developers. There is possibly a small potential market for a developer to provide very simplistic "tax only" type software (i.e. not doing any holiday tracking etc) but unless the cost of this was tiny why would any small employer bother.

In regard to general accounting software and tax compliance there are a few possible enhancements around GST, FBT, Prov Tax filing etc but again this would be popular with existing software users but would probably not really entice a new market.

hmmm forum cut off the rest

jethrocarr — Wed, 09 Jun 2010 03:02:21 +0000

hmmm forum cut off the rest of my message. Should have been:

It would be good to have different levels of compliance, or certification for compliance with specific features (eg: one for GST, one for PAYE, one for income tax, etc).