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).
JSON is simpler in many ways, but there are differences. The type of a simple value can be more than just text (as you have in XML), it can be null, boolean, number, or text. Javascript tents to just convert between things seamlessly in most cases. It does get to be fun in arrays where each value can be a different type, even an object or array itself.
JSON also makes it a lot easier to create and process using languages like Javascript, obviously.
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.
Subscribe to:
Post Comments (Atom)
Fencing
Bit of fun... We usually put up some Christmas lights on the house - some fairy lights on the metal fencing at the front, but a pain as mean...
-
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.
ReplyDeleteThat 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.
DeleteGreat work!
ReplyDeleteHow do you represent prices and monetary values? The implementations of numbers, especially non-Integers in JSON parsers is notoriously unreliable...
Well, using decimals, with typically 2 decimal places. In our system we are using arbitrary precision decimal maths. We're not typically expecting the external systems using javascript, etc, to be doing much maths, e.g. ordering will present product codes and quantities and be told exact calculated totals back.
Delete