Good news: HMRC offers a Linux version of Basic PAYE Tools. Bad news: It broke Did you know that His Majesty's Revenue and Customs (HMRC) offers free Linux tools? Sadly, though, they recently stopped working. Reg reader Pete Donnell alerted us to the fact that the UK tax authority offers a Linux version of its Basic PAYE Tools, which the download page describes as "free payroll software from HM Revenue …
Why is there a limit of 10 employees ? If it works for 10, why not 11 ?
No doubt that will end up being one of the things that gets fixed ..... Compare what happened when BitKeeper made their servers and a limited version of their proprietary client software available to the best Open Source developers in the world. The ensuing reverse-engineering effort naturally delivered an alternative client that comfortably out-featured the paid version of the proprietary client software; and when BitKeeper tossed their toys from their pram, that in turn led to the creation of git.
Unfortunately, Python isn't one of my weapons of choice; but I do know python3 needs round brackets around the arguments to print, which always struck me as highly un-Pythonic .....
The print as a function thing has confused me for years. I came to Python after a number of other languages where print was a function, so I never understood why it shouldn't be a function there either. It's the only imperative keyword, and without the parentheses, it still works exactly like a function would. Maybe someone who minds the change could explain why it's such a problem.
>Unfortunately, Python isn't one of my weapons of choice; but I do know python3
>needs round brackets around the arguments to print, which always struck me as
>highly un-Pythonic .....
I'm no Pythonist either, but it always struck me that not having round brackets was highly Cobolic. Shudder. I don't actually know Cobol, but the mere thought that something might be a bit like it (right or wrong) is enough to make me come out in a cold sweat.
And yet, a younger French acquaintance of mine purposefully set out to be a Cobol programmer. Yes, he's a bit odd like that. He's always busy...
python3 needs round brackets around the arguments to print,
"Real" python is written in c, and at the time of the change from 2 to 3, language design was dominated by the c coders. Part of the aim was to clean up Python by removing features that had been inspired by BASIC and Pascal, and were strange to the c programmers.
The narrowness irritated me at the time, because they knew nothing about mathematics, and were convinced that the c math library design decisions were the only possible way to correctly handle floating point numbers
It's tied into accounting requirements from what I remember of running a very small company. 10 employees is the limit for micro-entities which only need to file abbreviated accounts each year and are not required to have them audited. Any more than 10 and it starts getting more complicated and you'll probably be using an accountant or payroll services company to deal with it.
You get to file Micro Entity accounts which are even more abbreviated than "Abbreviated" accounts, basically a single page, or maybe 1.5 pages if you use a larger font.
50 employees is the limit for a small company which allows you to file "Abbreviated" accounts, typically about 6 pages.
I have precisely one employee (me!) but the whole payroll business is so incomprehensible and arcane that I still outsource it to a payroll company. I have 35 years in coding and systems design/analysis, but PAYE defeats me.
icon for me --------------------------------------------------------------------------------------------->
If the government provided free payroll software for every company, regardless of size, it would distort/destroy the market for such software.
Providing free software just for very small companies is a good idea as it supports small businesses who most likely wouldn't have the budget for the big commercial offerings in anycase.
The government should publish the reference implementation in Source Code form, and "effect on businesses" be damned.
No-one should ever be required to use a proprietary product (and thereby enrich someone else) simply in order to comply with the law of the land.
No-one should ever be required to use a proprietary product (and thereby enrich someone else) simply in order to comply with the law of the land.
The law requires, quite rightly, that I have lights on my bike at night. Should the government be suppling me with free lights (and batteries!) so I can comply with the law and not have to buy lights from proprietary manufacturers?
Bicycle lighting is a bad example. If there were only a few manufacturers of bike lighting systems jealously guarding their secrets, and no viable alternative to using any of them, then ..... probably yes.
However, you could comply with the letter of the law by only riding your bike in daylight, or even by making your own lights using some open technology. Rechargeable batteries and LEDs are available from multiple sources, and are made according to industry standards precisely so that any one can be substituted for any other; Laws of Nature also work in favour of common standards here. Other light-producing chemical reactions are also available.
Ah yes, the old "free market" ideology. Always works so well
Hahahaha. I'm actually someone who thinks capitalism is a bad system and something we need to progress beyond. Feel free to purview my comment history.
In the current system, I don't find it unreasonable that government provides free software for very small businesses.
(SysAdmin turned Accountant here)
I'm pretty sure there's no hard limit built into it - I've had to use it when filing corrections for previous years for a large number of employees. It's more of a "be aware of the limitations" message. Using it to actually run a payroll for any reasonably sized business would be Not Fun.
Same here.
However, around the time the person in the article claimed it stopped working, it switched from launching the internally bundled web browser to launching the system browser as a front end. No idea why.
It might be worth checking that xdg-open can launch a web browser on the system in question.
(OP here) Turns out it was a locale-related issue, and you're spot on that it coincided with the switch from the inbuilt browser to loading in the default browser. My admin machine is set to a non-Latin-based locale. After reading the comments here, I had another crack, and was able to get it running by forcing the locale back to English with 'LANGUAGE=en_GB LANG=en_GB.UTF-8 LC_ALL=en_GB.UTF-8 ./rti.linux'. For reasons that I don't understand, the old version where it used the inbuilt browser doesn't seem bothered by the locale settings, whereas the new version that runs the UI in the system browser very much does. Since it's written in Python 2, which is not good with UTF-8, it was hitting a character that it couldn't decode into ASCII, and crashing. I can't really blame HMRC for not testing this issue as I doubt many people will encounter it. However, the fact that they don't have a bug reporting program or indeed any reliable means of reaching them made it a lot more painful to diagnose than it would otherwise have been. Plus the fact that they haven't upgraded to Python 3, which has much better UTF-8 support baked in...
Font/Alphabet but not language.
Even English has a lot not Latin, though many of the Norman imports have Latin roots.
There are some Latin loan words in Celtic languages that predate Christianity on these Islands and may in some cases date more than 2,000 years. Cornwall and Cork cooperated in trading tin and copper for Roman and Greek bronze production. Hence the Latin for gold and silver in Celtic Languages.
When HMRC first issued PAYE Tools (as an alternative to the annual paper versions) they wouldn't work properly. Back then, I was running my own consultancy (not specifically IT focused) and, as an early adopter, I spent quite a bit of time liaising with them with fixes. To give them credit, they listened and took onboard my suggestions. Though don't ask me what they were - too long ago and I wound up my business 5 years ago (through choosing to retire and take a new direction with my time)...
In a past job I was involved with implementing payroll software from scratch. Including PAYE of course. This story makes me happy.
Yes that was a pain. I had a self-checking spreadsheet that ensured my returns were arithmetically correct and fed into my annual company return. So everything was consistent.
Now I have to spend more time filling in a portal company's spreadsheet knowing that my fumble-typing will inject random errors. The fact that the portal leader now charges for simply bridging this spreadsheet into HMRC computers is obvious travesty of the government's commitment to removing barriers and cost of bureaucratic regulation.
Good to say I found one that is still free. But for how long?
Having spent a miserable year working on a Python based system, I'd strongly suggest rewriting it in a statically typed language. Perl code was hellish to maintain at times, but Python code is even worse in my experience. Both languages have OOP features tacked on as an afterthought, and their dynamic nature means tooling is always going to be poor. I know there's optional typing with recent versions of Python, as well as add ons to also support it, but in practice it's very ineffective and even an IDE like PyCharm is unable to do much with it.
Python3 has type annotations. Use those, and Pycharm starts helping you. Better still, Mypy can find your bugs just like a static compiler.
It can get a little tricky to correctly describe what you mean for very dynamic code, but the effect of that is to make you write more "classic"-syled code.
I've tried MyPy but it doesn't really help, as lots of "pythonic" (or in other words, idiomatic) ways of doing things work against it and can't be statically checked.
I also spent a large part of that miserable year of Python programming having every code review peppered with comments about removing the MyPy type info I was using, since the other programmers didn't like having their "freedom of expression" limited. Yet almost every production issue was related to difficult to diagnose bugs that related to Python's dynamic typing.
I didn't say that type-annotating Python code was easy :-)
Most stuff (comprehensions, lambdas, etc) work OK. Recent versions of Mypy are also better than old ones.
The "freedom of expression" noobs need reminding that this is professional programming, and any source of improving code quality/shortening QA cycles is a good thing. Right up to writing slightly less dynamic, safer code.
In general, it is about documenting your assumptions ("this parameter has a .foobar() method", "this value might be None/must not be None" for example). If it is impossible to annotate those assumptions, then it may well be impossible to enforce them either. "Optional-poisoning" is Python's "const-poisoning, and requires similar levels of careful thought.
It sounds like your "miserable year" had more to do with your cow-irkers, rather than Python :-)
Static typing is a leftover from the days when you had to understand how data of different types would be stored and how much space it was going to take up.
Modern programming languages don't care what type of data you put in a variable. That's your business.
As, of course, is remembering what type of data you put in it.
Of course it is, but the reason we use compilers is to somewhat limit the number of stupid things we can do. We could go back to times where nearly anything you typed was valid code and the computer would run it, and if it didn't do what you wanted then that was your business to find out and fix. Powerful languages get their power by making it easy to explain what you want and difficult or impossible to do certain classes of preventable errors. Having enough memory that you don't have to think about type storage doesn't change all the other things that a good type checker can do.
I like Python, and it is one of my more commonly used languages both for prototyping and for some types of production software, but if I had one complaint about it, it would be that it makes some things which, in another language, would be compile-time errors into runtime errors. Testing is often insufficient and we don't make that easier by having to write pointless manual tests that a compiler would already do.
Testing combined with coverage tools and good coverage shakes out the typing issues pretty quickly. I work with both C++ and Python on a daily basis - so I get to have my cake, eat it and blow my toes off type-safety wise. From my perspective (having cut my teeth on K&R C in the mid 80s) it seems that encapsulation, type-safety and inheritance aren't really worth the hoops you have to jump through over the long run. I would trade them all for good quality unit tests every time. :)
The problem with that is that manually writing unit tests that test obvious behavior takes time, and that time could be better spent on tests that might help in the future instead of catching obvious stuff now. I've written a lot of unit tests that will never catch a real error because they effectively duplicate the code in a function. Either the function remains the same and the test will pass, or someone changes the function and will have to change the test, but it won't detect anything useful. I have written it because it tests some types and names, the same thing a compiler for other languages would do. If I didn't have to write that, I could spend the time writing a test which tests the boundary between two units, the places where changes to one area can cause a failure in another. I've worked on codebases where we had complete test coverage and where the tests would never do anything for us. By wasting time with tests that could be done automatically, we end up spending less time on the tests that prevent bugs later.
I also disagree about some features like inheritance. I find that well-structured types make certain design challenges much easier to get around than doing without them. Of course, Python has plenty of those features, and I use them frequently. Since I complained about Python's type system, I'll give it some praise now: one of its major strengths is the number of syntactic and structural ideas it has gathered from other languages and made available. For example, if something is best written in a functional language style, I can do that easily in Python while C makes it a pain. That is what makes Python such a good language for getting something functioning quickly; I can express what I want very quickly and accurately.
Fair play on your well thought out response, and apologies for the somewhat trite reply I offer by return (which does not directly invalidate the points you make):
Firstly there is absolutely nothing stating that you can't write Unit Tests that validate the boundaries between components.
Secondly if you are simply duplicating code you've written with your Unit Tests I would suspect that you should change your approach to writing them.
You are definitely correct about both things. The reason I bring them up anyway is that I've worked in many places where people wrote unit tests that were testing basic functionality because they occasionally caught errors made by the coders by testing every path, but that a compiler in other languages would have detected. I was required to write similar ones because otherwise, coverage reports would indicate that the function didn't test that the if statement did, in fact, execute the enclosed code when the condition was true. The time spent on unit tests like these that either did nothing or tested manually what a compiler could test automatically took out time. If I had insisted on writing even more tests that were actually useful, my performance would decrease and that doesn't end well.
This does not mean that I neglected useful tests, because I did try to include new ones whenever I thought the risk of someone changing a part was too high, but our project's testing was insufficient, and the time spent on pointless tests of basic things did not help. By all means, you can put the blame on my management for not caring about good tests or on me for listening to them. I certainly blamed myself every time I looked at our build tests which showed 40868 unit tests passed and gave me very little confidence that that meant anything useful.
Fair play. Have been there myself... Currently *retro-fitting* unit tests to ~250,000 lines of C++ written in layers with the structure and aesthetics of a demolished skyscraper - complete with mangled corpses, just to meet the "must have at least 70% coverage" diktat. There are some silver linings, for example I am finding a lot of unused and unreachable code that would have been shown up years ago if they had any tests at all, so quite a lot of that stuff is going directly to the shitcan (hurrah for coverage!).
Full disclosure: In this instance I am knowingly writing terrible tests because I have not been allowed the time & resource to fully understand the code and then re-write it for C++20x (it's written in pre C++0x with lots of third party libraries that are now superceded by C++17x stdlibs). These tests are awful because they are not really written to test out features of the code - they are written to provide coverage and by doing so fossilize the code in amber. The intention is that while I am not in a position to understand all the code, should someone make a change to the code (or change compiler / libraries etc) the tests are good enough to fail, thus (hopefully) forcing the poor sod into looking at the unit test and (hopefully) the code that blew up.
Not fan of this way of working either - but in this case I'm seeing some value in it as far as cruft removal and gaining some understanding of this production code that folks have been avoiding building ("It's too hard! Waaaaaaaaaaaah!") for nearly a decade...
Best of luck with your travels & travails. :)
Those sound like the words of an overconfident person to me. People trying to write something quickly can write a stupid thing even though they would be smart enough to avoid it in another circumstance. Have you ever looked at some code and thought "who decided that was a good idea", checked the logs, and it was you? I have. Sometimes, I know it at the time, so the code is helpfully labeled with comments about why this stupid thing is what I've done right now, but it should be improved at some point. You don't even have to write a lot of code to know that. Are you really saying you've never done something on autopilot and realized, usually right after doing it, that you shouldn't have? Of course, we try to minimize how often that happens and I think I've done well enough at that goal, but I'd be lying if I said it wouldn't ever happen again.
“ As, of course, is remembering what type of data you put in it.”
Please tell me you don’t work on anything critical?
Dynamically typed languages are for the lazy / uneducated. People with real expertise and knowledge can use these languages effectively - but 99% of users are totally inept. In particular rejecting static typed languages as being “old fashioned” displays ignorance rather than considered opinion.
I'm unsure just how you are using the term "users" if you mean end-users then they shouldn't have anything to directly do with variables and the type of a variable would be of no interest to them. If you mean programmer users then I suggest there are lots of problems if they are lazy / uneducated (and possibly employed by Microsoft).
Downvote me all you like, but that quote is incredibly insulting to the millions of people all over the world who are involved in Python one way or another. Not just Python, but any language effort that is not statically typed. It manages to be both woefully ignorant and elitist at the same time. This is like a debate at a student union. Plenty of old time programmers like myself have found our way to Python and we use it responsibly. The problem that this article mentions turns out to have nothing at all to do with Python. It was a locale issue. The Python 2 program, the language for which is four years out of support, still actually works. That's saying something.
Statically typed languages are great. I like C#, and dotnet runs well now on Linux. We mostly deploy apps to GKE here. We have some containerized stuff that was migrated from Windows server. It's fantastic that we could do that. And TypeScript is a good improvement over JavaScript. But mostly it's Python for the backend, and there is really no problem at all with that. Pytest makes it fun to write unit tests. They get run by the CI pipeline and ruff checks the formatting. JupypterLab is wonderful for prototyping. Application development has been steadily moving in the direction of cloud native for the past decade or so, I want to say. Desktop applications are on the way out. And Python is among the tools of our trade, so just deal with it.
My favourite episode of Grand Designs starts with a couple building a small house by hand. The lady is adamant - “I want to let it flow and we won’t be measuring anything, we’ll do it by eye and intuition.”
It goes about as well as you might expect - it’s very funny.
I’d suggest that any variable or object that might conceivably be used outside the function it’s declared in should be typed (and forcing yourself to scope things as tight as possible is a hassle you’ll thank yourself for later) - future you won’t want to visit you later with violent intent…
James: I haven't seen that episode of Grand Designs, but now that you've whet my appetite, I'll certainly look out for it.
It sounds very much like an old episode of Sarah Beeny's "Property Ladder" whose featured property refurb could have been reasonably described as a complete train wreck...
(The comments section should give you a taste of just how jaw-dropping this one is.)
Agree completely. The number of times that I accidentally put a number into a variable that should have contained a string (or vice versa) is precisely never. No amount of compiler checks would make the slightest bit of difference.
Where static typing does offer a benefit it is that it makes it much easier for your IDE to offer help.
Real programmers use ed, of course.
-A.
I'm glad to hear it. I'm pretty good at not doing that myself, having had a lot of experience, but I can't claim never to have done it, especially as I did it not too long ago. I was writing a basic HTTP client, and I checked the return code with something like
if status_code == 200:
Huh, I wonder why every request is showing an error? Is it that I'm not connecting to the right place? Have I incorrectly implemented the authentication? Did my quick client mess up a character encoding thing? No, I have to compare against a string status code instead of a numeric one but Python doesn't mind comparing a string and an integer for equality, it just always says False. A simple error, quickly fixed, and I probably wouldn't have made it if I was writing a larger program rather than a quick script (because the larger program would have abstracted out the HTTP stuff into one part that I would have focused my attention on when writing it), but I do make mistakes.
If you never make mistakes, that's great, but two things are still true. First, there are many people who do make them and it can be helpful to catch them without requiring them to go through long, otherwise pointless processes because they might try to skip them or they might make another mistake*. Second, I don't believe that you actually never make a mistake. I think you probably catch it quickly instead.
* In a project I worked on, every function would start by checking all its parameters for unacceptable nulls. Every unit test would start by testing all the parameters with unacceptable nulls. We pointed out that, if someone forgot to check for nulls, they would probably forget to test for the null they missed because everyone just wrote tests in the same order that their checks appeared which made it really easy to miss such a thing a second time if they already missed it the first time.
I respectfully suggest that it is because you didn't read (and absorb) the documentation.
This is the problem.
In mitigation, it's true that proper documentation seems to have almost completely disappeared from, well, everywhere. I understand that it was always a drag, but it continues to be necessary.
Totally obtusely I have to report that
if status_code == 200:
Would have worked just dandily in JavaScript.
There's dynamic, and dynamic.
-A.
"I respectfully suggest that it is because you didn't read (and absorb) the documentation."
No, it's because I was writing quickly. I read the documentation, which is how I know where the status code is, but I was using an HTTP client that I hadn't used before, and I forgot that it was a string. Generally, you have to understand the documentation, not memorize it. In either case, the bug was identified and fixed quickly. I'm just pointing out that a compiler that detected that I had effectively written "if False" would have pointed it out even faster, with no doubt about the particular cause. Of course, if I keep using this HTTP client library, then I'll begin to write if status_code == "200" all the time, and if I go back to a different one I know where they are integers, that's when my automatic entry will end up being the wrong thing.
Given that the API I was working with sometimes issued responses with 204, and they had to be handled differently, not so much. There's a reason they have more than one code there. Handling every 200 code identically is almost as bad as the time I saw someone's program doing a retry on every 4xx code, including 403 and 404.
That's a bad design decision at the language implementation level -- and it's foreshadowed by the inappropriate recycling of + as a concatenation operator.
If you are implementing a dynamically-typed language where numbers and strings can be freely mixed, you cannot just silently state that a number and a string are definitely unequal. That's a throwback to old-fashioned static typing, and at least would have thrown an error in an old-fashioned language. If the given string can be validly parsed as a number, and that is equal to the given number, then the two may be considered numerically equal. If every character of the given string is equal to the corresponding character of the default string representation of the given number, then they may be considered stringwise equal.
Perl gets this right, by using separate operators for numeric and stringwise comparisons.
PHP and JavaScript try to reuse < / = / > for both types of comparisons, and sometimes get it wrong.
That’s a very ... implausible description of Python, considering that
* Every value in Python is an object
* Every object is an instance of a class
* Functions and classes are also objects.
Now tell me, does that sound like “OOP features tacked on as an afterthought” to you?
> * Every value in Python is an object
After the Python 2.2 release, every value (including built-ins like integers) is a full objects on an equal basis with user defined objects.
It did take quite a bit of time, all of Python v1's and then a few releases of Python 2, before consistency was reached.
The reason Python is "popular" is because it's the first language you learn on contemporary CS courses. A few years ago it was Java for the same reason. JavaScript is also very popular, but it just seems like Stockholm Syndrome for programmers where they've just spent too long unaware of the alternatives and their relative strengths or weaknesses.
It's also the language used by a lot of people who aren't primarily programmers but need to program as part of their job. It's easy enough to learn and get something vaguely working, but having had to look at code written by scientists, I've never come across well written examples. It's usually what I call "stream of consciousness" coding - one long sequence of statements written on the fly, masses of duplication and buggy as hell.
And it was Python 3 code I worked on for a year (this was the backend to a supply chain and order management system, not the scientists' code I mention above). My experience of that was typical Python programmers don't use OOP properly, with every data member public for example because typing underscores is apparently too hard (a shit way of supporting data hiding anyway). Then the Pythonistas would whine that OO is "a broken paradigm" rather than admit they were too lazy to use it well.
As for tests, as someone points out above it was mostly testing for issues that wouldn't crop up with proper static typing. So huge amounts of effort expended on testing the language rather than the logic.
"The reason Python is "popular" is because it's the first language you learn on contemporary CS courses. A few years ago it was Java for the same reason. JavaScript is also very popular, but it just seems like Stockholm Syndrome for programmers where they've just spent too long unaware of the alternatives and their relative strengths or weaknesses."
No, I think you've got that backwards. You learn about it because it's popular and good, and you're likely to be using it professionally. I didn't learn about it in school. I'm 30 years out of education and Python has become my favourite language for most work. One of the reasons it has taken off is that it seems to have been very well suited for data science, and as a result the data science support has blossomed. What you say about scientists is true. I work with a lot of data scientists and they are not the best coders. But that's nothing against the language. You think this is bad? Try PHP.
On testing, you're off the mark there. Pytest is the best testing framework I've ever seen. No contest. And if you take a test driven approach, then you're writing tests at the same time or before you write your code. I'm a senior software engineer with over 25 years experience on all sorts of languages and platforms. I love Python and FastAPI for anything on the server and I love React with modern JavaScript for front end work. I don't know what you're talking about with testing the language rather than the logic. That has not been my experience, but again, if you approach unit testing and integration testing properly then that's not an issue. Every language has features that you're probably better off not exploiting. It comes down to experience.
As for OOP, it does have its issues and it's helpful to recognise them. Functional programming has a lot of inherent advantages. Interestingly, Python alleviates one of the problems with OOP by supporting multiple inheritance.
I can't agree with you about the reasons. Python was not the language I learned in introductory courses. It was not the language I learned in advanced courses. Many of those were taught in C or C++ for me, though I learned about ten languages more or less for some course. Python was used in exactly one course, or roughly 0.5 courses because that one used some others as well. If I just stuck with what I learned first, I would not use Python.
I use Python for some purposes because it makes it easy for me to express the intended computation quickly and generally accurately. My typical example is string parsing, where one or two lines of Python can do what would take twenty in C. If I need to parse a million such strings per second, then I might reimplement it in something faster, but in many cases, I need to parse a smaller number and it doesn't really matter how quickly, so the faster and more accurately I can chop them up and reconstitute the parts I care about, the better. This does mean that, as a program gets larger, I am less likely to use Python to write it, but that doesn't kick in as fast as it might for you. I have and will continue to write quite large systems in it when it is better than the alternatives.
Java would seem to be the obvious choice of language for this sort of application, since its well standardized and has an excellent set of standard classes for formatting text, whether printed on paper or displayed on a screen. Lastly, seeing that applications developed using any standard Java version can be compiled without any code changes on any other later Java version (i.e. running on different hardware or under a different OS), porting a Java application to different Java-supported hardware is a no-brainer.
Python gets a bad rap, but it is a strongly typed language with dynamic typing. Using mypy with python allows you to perform static type analysis of your code. If you are strict about your use of mypy, then Python is effectively a statically typed language. I work on an enormous modern python codebase, around 10 million LOC, all fully type hinted and mypy assured - we do not get typing errors.
I commiserate with the people who have to work with low quality colleagues who get mad about type hints.
Both languages have OOP features tacked on as an afterthought
Objects in Python are not an afterthought. Everything in python is a strongly typed object, with a class inheritance system, and has been since the first version Guido released.
> Everything in python is a strongly typed object, with a class inheritance system, and has been since the first version Guido released.
Almost, but not quite.
It wasn't until the release of Python 2.2 that the built-types all became objects on the same basis as user-defined objects. Prior to that they did not have the same status in the class inheritance mechanism.
Not for PAYE, but in case anyone is wanting to submit VAT returns using a (Python 3.7+) command-line tool: I'm the author of https://hmrc.readthedocs.io which provides a handy API and command-line interface for the VAT portions of HMRC's APIs. Try "hmrc vat login" followed by "hmrc vat obligations --all" and "hmrc vat return <key>" to get a feel for the tool. If you happen to have your VAT return summary data in a CSV file (one row per quarter) then "hmrc vat csv submit" will take care of everything for you.
I ran the installer on my Ubuntu 22.04.4LTS and it installed fine.
I had to right-click the desktop icon to allow launching and it opened my Chromium browser (Version 122.0.6261.94 (Official Build) snap (64-bit)) to 'http://127.0.0.1:46729/pages/home/'
I was going to post my running services and the like but that's probably a bit much for a forum post :-)
Maybe run an update on your fresh install VM before installing?
I've used BPT since it became available (and the Linux version in particular so long as it has been around) and although it might not be perfect it's about a thousand times better than most other payroll software I've had the misfortune to use or assist with. When they ask for feedback I always make a point of commending them for making the Linux version available, it ought to be mandatory for government issued software.
Basic Paye Tools is working for me under Ubuntu 23.10. Just about
I had big problems a couple of years back, eventually solved by switching from the inbuilt browser in the package to the system default (Firefox). I think I needed to do something to make the right Python version get used as well. And, for me, it only works when initiated from the command line. And then you see a whole pile of interesting debug messages on the command line.
Getting support was frustrating. You have to go to the telephone support line. They don't really understand and just pass messages to and from the actual support. It took me three months to get the problem I had two years ago sorted out. They did refund the 200 pounds for late submission of returns that resulted.
I get the impression that there is maybe one, part time, developer supporting this code. And that no-one dares, or has the time to touch it. Hence no update to new Python versions and no fix for the internal browser.
Distributing poorly supported software like this is crazy. Obviously if software is distributed, then there definitely should be a non proprietary platform available (Linux).The way platform independence *should* be achieved is to have a web interface for everything, like there *used* to be for VAT. No artificial limit on size of enterprise. Plus a public API for bigger users, who will naturally prefer to integrate with their own (or third party) software. The way they dropped the web interface for VAT, forcing small users to use portals (free for now) that also have an (inferior) web interface.
The BPT Linux versions is obviously extremely fragile. This year's regular tax year change update produced a version that just froze when I first ran it, giving a nasty looking error message in the command line. Then I just ran it again and it worked. It is a little scary having to rely on software like this for a legally required business function.
For the 1%, that is.
A country that can't manage its healthcare properly, can't be arsed to manage its procurement or salaries at a county level, keeps spaffing billions to foreign companies for useless IT projects, can't offer a proper administrative portal that actually handles things for the plebs, has endless amounts of Prime Ministers who don't give a fuck and yet, it still manages to support a withering, useless monarchy and pretend that it still has an empire.
Way to go ?
Hang on. Let me Google that for you. It's licensed under its own open source license called the PSF (Python Software Foundation) LICENSE AGREEMENT, the terms of which you are free to read. You can always submit patches to the maintainers if there is source code available. They are under no obligation to merge them. There is of course source code available, otherwise the project could not really even pretend to be open source.
Not sure what point you were trying to make.
If I was the Inland Revenue, I would just publish the tax calculation algo/flowchart.
Within 30 days, all the versions/ports you could possibly want would appear in Github and you'd save a fortune on it.
All we ever really wanted was clear instructions on how to calculate tax. We can do the rest.
int main(enter the void)... The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
