Home » Articles posted by martinjquinn (Page 2)

Author Archives: martinjquinn

A different approach to cloud accounting software

(Image from Sage.com)

Sage (a leading provider of accounts software) have recently extended their most popular product to the cloud. And they have done to in a way which seems to address a lot of concerns.

My experience of cloud accounting software is that while it is functional and easy to use, it does lack some of the capabilities that desktop accounting software offered. What Sage appear to have done is taken their best product for SME – Sage 50 – and retained the best of both worlds. The news release at the link above suggests a new product, Sage Drive, allows the user to retain the desktop functions but store data in the cloud. This has several advantages. First, the sharing capabilities of the cloud are available once the data is stored there. Second, existing functions are maintained and this may particularly suit the accountant users. Third, it may ease some security concerns accountants often mention with the cloud. From my understanding, only the data is cloud hosted. Some desktop software is still needed to make sense of the data.

Technology number 2 concern of Boards

A recent report cited on CGMA’s website places technological risk at the second risk concern amongst a survey of Boards of Directors. The risk concern is with cyber-security, and was the number one risk concern of private firms. The report notes an increases in the perceived technology risk from previous years.  It is interesting (and good) that Boards are well aware of technological risk – as most large organisations today are so reliant on their information systems. You can read the full report here and the CGMA article here.

The cloud – Dropbox

Here is a nice new feature from BBC on cloud storage company DropBox

Technological progress 2

Following from our last post, have a look at this:


I came across it on a social network. If you are a student, you may be too young to remember when Internet speeds were 64Kb per second or so – yes that’s Kb not Mb per second. Nowadays 40-50 Mb is normal at home and in business. That’s nearly 1000 times faster.

Technological progress

Here’s are very simple graphic which shows how technology has progressed in 9 years.

Big data problems

It’s bollocks, quotes an interesting article from The Economist – see this link

Mainframes 50 years old and still in use

In Chapter 1 of our book, there is a brief history of computing. The mainframe computer is 50 years old and this BBC feature gives a brief summary of their history. And as the article notes, they are still in use today.


iXBRL in action – Ireland’s Revenue Commissioners

Image reisgtered to XBRL.org

From late 2013,  most larger Irish companies have to file their financial statements in iXBRL format. As you learned in Chapter 7 of our textbook, iXBRL is an embedded form of XBRL. The Revenue Commissioners – Ireland’s tax authority – provide lots of useful information on iXBRL at this link. It is worth having a read through these pages as it brings Chapter 7 to life.

Excel tips – INDEX and MATCH

Here is a link to a very useful exercise on the Excel INDEX and MATCH functions. These functions are useful for looking up data in spreadsheets.

Inbound interfaces – an example from SAP

As you might imagine, any business that starts using a system like SAP will most likely want to transfer data from their old system. This might be anything from customer details, to open invoices on customer/supplier accounts, to closing ledger balances. Transferring can be done two ways, manually to using an interface.

Ultimately, using an interface is probably best as it automates mundane work and is likely to be less error prone than manual entry. For example, can you imagine and organisation with 2,000 customers, each with 5 outstanding invoices? That’s 10,000 entries to be made manually – not an ideal scenario. So an interface would be the best option, but what is an interface?

In this case, we can describe an interface as an agreed format to transfer data from one system to another. SAP for example uses a concept call iDocs to not only transfer data within SAP, but also receive data from outside.  You can think of an iDoc as a simple text file, with lines of text. The first line is a control record, with each line thereafter a data record. In simple terms, the control record tells the system where the data which follows is to go. Each record (line) in the iDoc is 1,000 characters long, and the position of each character determines what the data means – the positions are defined by SAP. Here is an example of what an iDoc record might look like:

ORDERHEADER 1088    1089    12500.50   24121998 Micky Mouse

Normally, a programmer develops some programme code which can extract data from the sending system to comply with iDoc format. Then, when the programme is run, the iDoc is read by SAP and the relevant data fields are populated e.g. customer details, open invoices.