For UK users: Will gnucash get ready for Making Tax, Digital ?

Alain Williams addw at phcomp.co.uk
Tue Aug 1 06:24:19 EDT 2017


On Mon, Jul 31, 2017 at 02:13:48PM -0500, GWB wrote:

> But who knows.  I'm averse to having information stored in a digital
> format on government servers because it will eventually be hacked,
> stolen, or otherwise used for something other than the original and
> limited intention (you can pick your favourite bogeyman here; your own

Ditto for 'free on-line apps' that government seem to be fond of promoting as
the solution to MTD. I want to keep control of my own data; not have is data
mined and sold to the highest bidder by some 'free' web site. I also have no
intention of doing my accounting via my mobile 'phone.

> FOSS doesn't work for the reasons Buddha Buck outlined, and more.  It
> would be great if someone volunteered to work on a txf export template
> for MTD.  Beyond that, I'm not sure how the devs would "hard wire" MTD
> (or other jurisdiction specific) features into gnucash that would meet
> the requirements of the Swedish or UK governments.  That sounds like a
> lot of extra effort even if it were possible.  I think Alain has it
> right, and perhaps its easiest to use the txf export from gnucash to
> import to another program.

Ideally this program could do the MTD reporting/connect-to-hmrc-servers
directly. It would be as small as possible. This would leave the bulk of the
work inside gnucash.

The rubbing point of a 'secret' in-built key/program-id (if HMRC remain obdurate).
The program could be Open Source but closed build: by which I mean all of the
source could be open except for the key - which would be a few lines of
string/something constant brought in by a #include. This could then be packaged
up (RPM/DEB/...) and made available for free use.

There is no guarantee that HMRC would accept this. They seem to be keep to
validate the accounting program and the secret key in the comms module is their
way of doing this. They might decide that they want to validate the identity of
more than the transfer program -- after all this program would accept an export
file from anything that can generate a syntactically correct format.

I could see this program being used with other accounting programs (ie non
gnucash) that share this MTD problem - that is the nice thing about having a
well defined interface.

Such a program could be used as basis of a family of 'export' programs needed by
various governments; we can expect this sort of requirement to become more
widely mandated. Some of them could be truly Open Source, others (as in the UK) might
need to be Open Source but closed build.

This ''Open Source but closed build'' is not a problem from the licensing point
of view. If I write a program from scratch I get to choose the license; no
reason that I cannot choose GPL with a couple of extra paragraphs. Which
repository the Debian guys put it into - is their discussion, not mine. [[I'll
start a chat with a Debian maintainer friend of mine.]]

I am still willing to work on it. But I will need some help.

> You might be stuck with using gnucash for the bookkeeping, and then
> digita for the reporting.  I agree that is "sub optimal", but that
> describes tax compliance in most jurisdictions.

> Out of curiosity, who wants MTD?

I don't. It will involve me in a lot of extra work that adds nothing to my business.

I am happy with doing VAT on-line -- just login to HMRC web site, enter a few
numbers into a web page, download a PDF and transfer some money - simple.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>


More information about the gnucash-user mailing list