I have a feeling that industry is moving away from XML and towards JSON...
Just a feeling, but even HMRC, who used to used XML for VAT and do for RTI, have moved to JSON for MTD (VAT).
Fundamentally XML is too complicated - especially with name spaces. The options in XSD (which is the common way to define what is valid in an XML file) is also a bit of a mess - defining the order of the XML objects even, which is a pain if you ever work with any XML. JSON does not expect values in an object to be in any order (just in an array).
As it happens, at A&A, we have been working on new APIs for our control systems (more on that another day), and these are all JSON based too. But this week I have started on some work on the accounts system.
I now have JSON for documents, i.e. invoices. We currently allow customers to access invoices in XML, PDF, Plain text, and HTML, and as of now also JSON. You can ask for a JSON attachment to be automatically included in your invoice emails if you wish - digitally signed, obviously.
Whilst we have loads of work behind the scenes improving the way the accounts work, this JSON interface should be pretty stable now.
JSON all the things
Subscribe to: Post Comments (Atom)
Companies bad at banking
I was discussing with a colleague the other day how so many companies are so bad with banking. In some ways we have been lucky, but to be fa...
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...
For many years I used a small stand-alone air-conditioning unit in my study (the box room in the house) and I even had a hole in the wall fo...
It seems there is something of a standard test string for anti virus ( wikipedia has more on this). The idea is that systems that look fo...
If you are making a few changes to the internal accounting systems may I suggest something? I wouldn't bother with all the allocating of payments to specific invoices. I would just do debits and credits. Legally a credit is allocated to the oldest debit, then the next oldest, etc. so any allocation that deviates from that is only superficial anyway.ReplyDelete
That is exactly what it does by default, allocates any payment to oldest date (by due date). If all things are paid within terms, in any order, that is always fine. But customers wanted to mess about, pay some invoices with specific payments and some other invoices late. Indeed, when we first added this feature, as someone asserted that they had paid specific invoices, we allocated as requested and it meant their late payment penalties actually increased as it changed which ones (and how many) were now late! But auto allocation in order remains the default.Delete
How do you represent prices and monetary values? The implementations of numbers, especially non-Integers in JSON parsers is notoriously unreliable...